Wątek być może banalny ale mam takie przemyślenie odnośnie tego wszystkie i jestem ciekawy jakie są Wasze doświadczenia, szczególnie osób z długim stażem używania FW. Ilekroć chce użyć czegoś gotowego i tak brakuje w tym jakiejś opcji, ostatecznie trzeba stosować jakieś ominięcia, napisać własną wersję lub stosować inne dzikie kombinacje. Oczywiście piszę o czymś większym niż strona wizytówka, o większych projektach, które mają być rozwijane przez lata.

Czy faktycznie po latach używania FW korzystacie z czegoś więcej niż podstawowe funkcjonalności jak zaprojektowany model MVC, CRUD itd.? Czy nie jest tak, że ostatecznie i tak napisaliście wszystkie gotowe moduły samemu?

Jedna z najważniejszych cech programisty to... bycie leniwym Z czasem zauważysz, że zanim zaczniesz pisać sam, przejrzysz sieć w poszukiwaniu czy ktoś już tego nie zrobił. Początkujący chcą pisać wszystko sami, inteligentni podejrzewają że ktoś już to napisał i szukają. Senior developerzy wiedzą gdzie szukać

Niby tak, ale gotowe rozwiązania po pewnym czasie okazują się nie spełniać wszystkich potrzeb. Oczywiście nie mówię o wszystkich komponentach, bo znajdą się takie, które spełniają wszystkie potrzeby. Chodzi mi jednak o proporcje gotowców do własnych rozwiązań.

Pisanie własnych rozwiązań na coś co już jest jest po prostu droższe.
Nie dość, że schodzi dużo czasu na napisanie, to jeszcze trzeba potem to utrzymywać. Nigdy nie jest tak, że coś co zrobisz będzie wolne od błędów, które np ujawnią się po roku przy okazji jakiejś dziwnej/nieprzewidzianej akcji.

Z mojego punktu widzenia:
- ogólne biblioteki "atomowe" typu tworzenie PDF czy wysyłka maili - gotowce,
- moduły do frameworka - własne.
Często zdarzało się tak, że jakieś rzeczy drażniły mnie w gotowych modułach, części funkcjonalności brakowało, część była dla mnie zbędna. W tej materii jestem raczej upierdliwy i wolę mieć moduł dostosowany do swoich potrzeb. Przykładowo moduł Auth z Kohany: jak dla mnie upierdliwym rozwiązaniem jest logowanie użytkowników tylko z rolą "login". Od lat jestem przyzwyczajony do osobnej kolumny prawda/fałsz. Również przyzwyczaiłem się do realizacji kolumn prawda/fałsz jako BOOLEAN (w PostgreSQL) oraz ENUM('f','t') (w MySQL) i bawienie się tutaj intami po prostu mnie razi. Jeśli ktoś nie jest upierdliwy i nie przeszkadza mu "bałagan" to może brać gotowce. Ja wolę pisać własne moduły tym bardziej, że wówczas znam je od podszewki i jestem w stanie je zmienić tracąc jedynie czas na faktyczne modyfikacje, a nie na główkowanie jak je wprowadzić.

Z tego co czytałem jakieś arty to enum nie jest zalecanym rozwiązaniem.
Z mojego punktu widzenia mieli racje - 0/1 w PHP dobrze odzwierciedla boolean.
Przyjmując że masz kolumnę "suspended" i programista po Tobie pobiera obiekt usera i robi takie wyrażenie:

[PHP] pobierz, plaintext 
if ($user->suspended) echo 'Masz bana'
[PHP] pobierz, plaintext 

No i każdy ma.

Po latach pracy z FW sporo osób ma juz dopisane / zmodyfikowane klasy do swoich potrzeb. Ja mam kilkanaście modułów ktore tylko przerzucam do kolejnego projektu, dopisuje w konfigu i wszystko zaczyna działać (oczywiście zdarzają się drobne modyfikacje pod dany projekt, ale szkielet jest zawsze taki sam)

Głównie pracuję z PostgreSQL i tam prawda/fałsz reprezentowane są właśnie poprzez 'f' i 't'. Tworząc moduł uniwersalny dla różnych baz (w tym przypadku MySQL) staram się odzwierciedlić te wartości. Poza tym chociażby przy edycji danych w phpMyAdmin kolumna ta wyświetla mi się jako radio z tymi 2 możliwościami wyboru, a nie pole do wpisania liczby - dla mnie to "przyjemniejsze" dla oka. Masz rację co do warunku, ale nie do końca. Jeśli w kolumnie może być NULL to wartość będzie pusta i wówczas mogą wystąpić problemy. I tak będzie konieczne sprawdzenie czy jest tam 0 czy pusty string. Ja mam napisane proste helpery do translacji 'f' i 't' na logiczny boolean i odwrotnie - z boolean na 'f' i 't'. Jak wspomniałem: to kwestia przyzwyczajenia, dla mnie wygodniej jest operować na 'f' i 't'.

Zależy do czego. Jako reprezentacja typu booleanowskiego w MySQL sprawdza się porównywalnie do bit oraz tinyint (dla MyIsam ma nawet lepsze [minimalnie] osiągi przy insertach). Z punktu widzenia zajmowanego miejsca CHAR(0) z możliwością przyjęcia NULLa sprawdza się najlepiej dla innodb i tak samo dobrze jak bit dla myisam. Różnice są tak minimalne, że dla zdecydowanej większości osób, nie będzie to miało żadnego znaczenia, co używają i decyzja zależy wyłącznie od gustu / przyzwyczajeń.

To złe rozwiązanie, bo z więcej niż jedną kolumną ENUM w jednej tabeli są problemy.



MySQL BOOLEAN == TINYINT(1)

Biorąc pod uwagę że w postgresie boolean rozwiązuje się podobnie jak w php czyli true/1/t/yes/on to chyba lepiej dla kompatybilności używać 1/0.

Możesz rozwinąć ?

No coś ty, dopuszczenie NULL w moim przykładzie byłoby błędem w strukturze.
Suspended powinno mieć wartość domyślną 0.

Ogólnie wole tinyint ponieważ czasami jakąś kolumnę status np. 0 i 1 ale w trakcie rozwoju chciałbym dodać nowy status -1 (np. "odrzucony", "zablokowany") i gdy mam tinyint to dodam go bez zmiany struktury bazy.

A ja mam takie pytanie, co sądzicie o CHAR(1) zamiast TINYINT(1) ?
Przypominam że w MySQL wartość w nawiasie dla intów nie jest tym samym co dla CHAR czy VARCHAR.
TINYINT(1) i tak dopuści 127 lub (255 UNSIGNED)

Co do tematu:

Jeżeli chodzi o paczki, które są duże, a co się z tym wiąże napisanie ich od początku = duże koszty (nie mówiąc już o ich utrzymaniu) to używam gotowców: TCPDF, Smarty/Twig, SwiftMailer, HTML Purifier.
Naprawdę nie ma sensu pisać powyższych bibliotek od nowa - tylko masochiści to robią (chyba, że ktoś ma na prawdę dobre nowe podejście do tematu)

Czasami zdarza się także jakaś pojedyncza biblioteka, z GitHuba (jeżeli licencja na to pozwala) tak przykładowo mam klasę do obiektowej obsługi reCaptcha.
Natomiast w większości staram się tworzyć własne uniwersalne i proste do rozwijania rzeczy lub wzorować się na istniejących.

Także jestem podobnego zdania jak phion

Ile ludzi tyle opinii na ten temat, jak to mówią każdy orze jak może.

Są aż trzy argumenty przeciw:
1. CHAR przechowuje dodatkowe dane w bazie danych jak np. kodowanie znaków dla danej kolumny, a TINYINT nie
2. Co jak ktoś będzie modyfikował to co Ty robiłeś? Przyjdzie chińczyk i skąd ma wiedzieć, że P = Prawda, F = Fałsz albo Y = Yes, N = No? A 1/0 to uniwersalne true/false
3.

[PHP] pobierz, plaintext 
<?php
 
echo (bool)'Y'; // true
echo (bool)'N'; // true
echo (bool)"1"; // true
echo (bool)"0"; // false
 
?>
[PHP] pobierz, plaintext 

No tak, ale używam wartości numerycznych 0, 1 lub jeżeli są jakieś inne wartości to np: 0, 1, 2, 3
Nie używam do oznaczania stringów: P, F

Kolumny w bazie posiadają komentarze opisujące co dana wartość oznacza.
Więc nasz chińczyk musiałby być mało rozgarnięty umysłowo, aby tego nie zrozumieć, a takich ludzi nie potrzebuję

Jak najbardziej w takiej sytuacji pasuje mi to że PHP po zrzuceniu 0 na boolean zwraca FALSE, a 1 - zwraca TRUE.

Czyli argument 2. oraz argument 3. w tym przypadku się nie pokrywa.

Tutaj w ogóle nie rozumiem o co Ci chodzi.



No tak... ale według Ciebie dać jakieś dane w bazie danych, opisywać innym w komentarzach co one robią i jeszcze zmuszać ich do wejścia do bazy danych, żeby to przeczytali? Prościej chyba dać 1/0.





W czym się nie pokrywają? Pokrywają się doskonale.

Działam na 0/1 tylko, że używając pola typu CHAR(1), a nie TINYINT(1)
Czasami zdarza się także sytuacja, że pole CHAR(1) jest flagą posiadającą inne znaczenia niż [0 - Wł/Tak, 1 - Wył/Nie]
Przykładowo: styl formatowania ceny:

0 = 1000.00
1 = 1000,00
2 = 1 000,00




Po to jest możliwość komentowania kolumn w bazie danych, aby z tego móc korzystać.
Nikt nie mówi o zmuszaniu ich do wchodzenia do bazy danych.
Bazy danych są projektowane przykładowo w Workbenchu, więc wystarczy otworzyć diagram bazy lub mieć IDE zintegrowane z bazą.



Argument 1. Zgadzam się jest to wada tego rozwiązania.
Argument 2. Nie pokrywa się ponieważ chińczyk musiałby być mało rozgarnięty, aby pomimo komentarzy nie wiedzieć co oznacza dane pole (jego wartość) w bazie danych.
Argument 3. Nie pokrywa się ponieważ używam [0, 1] i pasuje mi to że PHP rzuci mi FALSE w przypadku rzutowania 0 na BOOL, oraz TRUE w przypadku rzutowania 1 na BOOL. Z reguły i tak tego nie robię tylko sprawdzam (Wartość > 0)

A temat cały czas był o zagadnieniu boolean w bazie danych. Więc trochę tak temat o zupie, a Ty o dupie



Korzysta się z nich kiedy są potrzebne. Wszystkie funkcje w PHP też są po to, żeby z nich korzystać. I co? Do programu "Hello world" użyjesz ich wszystkich ?




No tak, ale to znowu wymuszanie, że ktoś coś musi mieć.




Załóżmy, że dostałeś zlecenie za niezłą sumkę od kogoś z kraju z dziwnym językiem, gdzie np. "boobies" oznacza "prawda", a "jellyfish" oznacza "fałsz". I teraz jak zauważysz, że w bazie jest kolumna ENUM('B', 'J') domyślisz się, które to prawda, a które to fałsz? Czy jesteś nierozgarnięty?



A ktoś kto rzutuje przyjdzie, żeby coś zmodyfikować w skrypcie i już szykuje się debugowanie.

Nie koniecznie,
Moje pierwsze pytanie brzmiało: co sądzicie o CHAR(1) zamiast TINYINT(1)
I do tego dążyłem, dodałem jednak zdanie o innych wartościach niż (0, 1), aby podeprzeć mój argument o komentarzach.


Komentarze są zawsze przydatne, albo stawia się na konsekwentność w ich tworzeniu albo lepiej sobie w ogóle darować, jeżeli komentarze raz są a raz ich nie ma.
A potem programista musi gdybać... "A może ktoś napisał komentarz co oznaczają te wartości ? ... Oj jednak nie"
Coś co dla ciebie może być nie potrzebne (bo wiesz o tym na ten moment - kiedy projektujesz) dla kogoś innego kto dosiadł się do tego projektu może być konieczne, dla ciebie po pewnym czasie także (człowiek często zapomina o takich rzeczach)



Jeżeli ktoś pracuje przy projekcie musi trzymać się ustalonych dla niego standardów



Jeżeli byłby komentarz dla tego pola w języku uniwersalnym np. Angielski to owszem domyślił bym się (Tak jak to tłumaczyłem, byłbym nierozgarnięty gdybym pomimo komentarzy nie wiedział dalej o co chodzi)



To może sobie zrzucić, będzie miał ten sam efekt co zrzucenie wartości z TINYINT(1)
I warunek (Wartosc > 0) także przejdzie:

[PHP] pobierz, plaintext 
False > 0 // false
True > 0 // true
[PHP] pobierz, plaintext 

Tu jest ciekawy (dla mnie) artykuł na ten temat.

Ja osobiście nie widzę żadnego plusa używania CHAR(1) zamiast TINYINT(1), więc poza tym co już Ci wskazano na korzyść TINYINT to ja dorzucę np do Twojego formatowania uwagę że na TINYINT mogę sobie przyjąć że 2 oznacza zamień kropkę na przecinek a 4 oznacza stosuj spację do oddzielania. A tak na poważnie zarzuciłeś temat, wytykają Ci błędy, Ty się bronisz "ale to, ale tamto", może lepiej napisz jakikolwiek plus jaki widzisz z zastosowania CHAR(1).

Zadałem pytanie, otrzymałem od pyro 3 argumenty przeciw.
Z jednym z nich się zgodziłem dwa argumenty podważyłem, ponieważ nie pokrywają się z tym w jaki sposób jest używany przeze mnie CHAR(1), a jest w moim przypadku używany jak TINYINT(1)

CHAR(1) zadziała tak samo jak TINYINT(1), a jedyna wada tego rozwiązania jaka została podana to to, że CHAR przechowuje także informacje o kodowaniu.

Nie określiłbym używanie CHAR(1) jako wytykanie błędów, błędem mogłoby by być używanie ENUM, który zachowuje się dosyć dziwnie.
I wcale się nie bronię, tylko dlaczego mam przyjmować argumenty, które nie są prawdą ?

Nie podam plusów korzystania z CHAR(1), ponieważ po to zadałem pytanie, aby dowiedzieć się co przemawia za tym, aby zamiast niego używać TINYINT(1).
Otrzymałem jedną wadę (przechowywanie dodatkowych danych nt. kodowania) i jest w porządku, po co drążyć temat.

Poza tym znalazłem w dokumentacji MYSQL:



Czyli sami zalecają używanie TINYINT(1)

Pozdrawiam

Panowie, proponuję zakończyć temat obsługi prawda/fałsz i trzymanie się głównego tematu dyskusji.

Ze swojej strony na koniec dla pyro:
Nigdy nie odczułem problemów z kilkoma polami ENUM w jednej tabeli. Podałeś screenshoty z phpMyAdmina. To, że on sobie z tym nie radzi nie oznacza, że sama baza też sobie z tym nie poradzi.

Nie podważyłeś i nie "nie są prawdą". Tylko Tobie się wydaje, że nie są prawdą. A to kolosalna różnica. Problem w tym, że nadużywasz sformułowań typu:





Pewnie, że w Twoim przypadku będziesz wiedział o co Ci chodziło. Tylko z czasem człowiek zamiast uczyć się programować, uczy się jak programować solidniej / lepiej / szybciej / bardziej uniwersalnie / łatwiej przy rozbudowie. Z czasem do tego dojdziesz.

Przypomina mi się sytuacja, w której dostałem pewien skrypt (miałem zrobić do niego płatności). Ładnie udokumentowany, z komentarzami, ale patrzę - jeden plik pominięty. A jak się pytam czemu pominięto ten plik, to uzyskałem odpowiedź: "bo ma tylko kilkadziesiąt linijek kodu". Pewnie, że to mały plik. Pewnie, że rozpracowanie go to tylko kilka minut. Ale czemu mam tracić te parę minut, skoro mogłem mieć wszystko od razu jasne i na tacy?



Używanie ENUM nie jest błędem. Niestety niektóre menadżery robią z nim (nie wiedzieć czemu) problemy (jak na podanym przeze mnie przykładzie), więc jest to jakby wada stworzona przez nie.



A no.



Zadałeś pytanie. Otrzymałeś odpowiedź. Co Ty uznasz w niej za prawdę, a co nie, to już Twoja indywidualna sprawa. Ja już skończyłem z dalszym wyjaśnianiem "dlaczego", bo niestety widzę, że idzie to dość topornie.

Tak naprawdę nie ma to większego znaczenia, którego z nich użyjesz. Różnice są znikome. Ale jak już wybierać której używać, to dostałeś 3 argumenty, a potem sam dopowiedziałeś sobie jeszcze jeden sam:



Także tyle w temacie.



To był tylko jeden przykład. Jak chcesz mogę dać screenshoty z innych programów, które też robią problemy . Nie wiem dlaczego one robią kłopot, ale w każdym razie robią.

Jeżeli mimo moich wyjaśnień, nadal uważasz że wszystkie argumenty przeciw są w porządku, to albo nie czytasz w ogóle moich postów, albo jesteś tak zaślepiony swoją ideologią, że nie dochodzi to do Ciebie.



Nie znasz mnie, więc nie wchodziłbym na grunt podważania kompetencji, tego czego się nauczyłem lub nie nauczyłem, lub "w przyszłości do tego dojdę".
W ogóle nie rozumiem z skąd i po co napisałeś to zdanie, co ma używanie TINYINT lub CHAR do bardziej uniwersalnego kodu, łatwiejszego przy rozbudowie.
A to o czym pisałem na temat komentowania kodu i kolumn w bazie danych jest właśnie odzwierciedleniem tego że wytworzony produkt jest wtedy łatwiejszy do rozwijania, piszę się w nim lepiej i szybciej.
I to ja ponoć gadam o "dupie"



Ty w ogóle czytasz co ja pisałem? właśnie o tym mówiłem cały czas, że komentarze są zawsze potrzebne, to ty powiedziałeś że komentarze są po to, aby używać je tylko wtedy kiedy są potrzebne, trochę podjeżdża mi hipokryzją.



A ja skończyłem z dalszym przekonywaniem Ciebie, że w określonym przeze mnie przypadku dwa twoje argumenty się nie pokrywają. Mam wrażenie, że cokolwiek co nie zgadza się z twoją odpowiedzią traktujesz jako atak i nawet nie próbujesz zrozumieć, a to bardzo nie przyjemne, bo zaczynasz odwracać kota ogonem i przyciągać jakieś historyjki, które zaprzeczają twoim wcześniejszym odpowiedziom.



Otrzymałem tak na prawdę jeden argument od Ciebie, bo jeżeli uważasz, że dwa podważone przeze mnie są jednak słuszne, to także zaprzeczasz, że używanie TINYINT jest lepsze, ponieważ CHAR(1) w określonym przeze mnie przypadku jest używany tak samo jak TINYINT, a nie jak ENUM
I na tym ten temat powinien się już dawno zakończyć.

Dobra chyba starczy na temat BOOLEAN w MySQL. Znowu mógłbym tłumaczyć dlaczego to co mówisz w większym lub mniejszym stopniu jest nieprawdą, ale Ty powiesz, że ja się upieram, ja równie dobrze móglbym powiedzieć, że Ty się upierasz przy swoim, będzie to szło dalej topornie i w rezultacie dojdziemy do niczego. Zresztą nie chce mi się już dalej tego ciągnąć, a poza tym zrobił się za duży OFF-TOP.

Informacja dla potomnych: posty są, wystarczy przeczytać, sami uznacie co jest prawdą, ale jednak którego z typów lepiej używać zostało jednoznacznie uznane.

// EDIT



Nie miało to w jakimkolwiek stopniu charakteru ofensywnego.