Mysql да, нет, null

[Redjik]

Есть несколько полей с true,false,unset значениями...
Руки так и чешутся сделать вариант tinyint 0,1,2
Потом в коде сделать что-то типа

if ($value)
{
   echo $value===1?'Нельзя':'Можно';
}

Хотя правильнее null, но там условие не такое наглядное получается. + null больше места в бд займет...
Опять же - не обложит ли меня матом програмер, который в будущем когда-нибудь дорвется до этой базы?

Можете поругать за глупый вопрос.

 

[Ragazzo]

Я бы обложил, ну просто я исхожу из той логики, что если значение поля вообще логически никак грубо говоря трактоваться не должно, то NULL, а у тебя тут просто обычный перечисляемый список, соотв. tinyint ну или varchar (1), для извращенцев))

 

[Redjik]

тогда уж char(1)

Ладно сделаю null...

 

[fixxxer]

Если null - это null в терминах SQL - то null.
Если на самом деле не null, а некий Undefined, который такое же значение, как и все остальное, то enum.

 

[Ragazzo]

fixxxer
Ага, я о том же)

 

[Redjik]

fixxxer
Ага про enum тоже думал - кучу null сделал в итоге...

Смотрим дружно яндекс недвижимость... есть там такие поля - можно ли арендовать квартиру если у вас есть животное...
Если не указано - то и на сайте не отображается (null логика),
Если не указано, то и в поиске не учитывается (null логика)...

Если указано, то может быть только или да или нет...

 

[Василий М.]

ИМХО null в БД нужен. 99% программистов туда тупо 0 или '' записывают, а это идеологически не верно.

 

[С.]

Как раз очень даже верно. Все работы с null могут происходить только на низком или платформозависимом уровне. Для веб-приложения с его передачей данных по HTTP как раз идеологически противно на уровне модели использовать null.

 

[Sufir]

Как раз очень даже верно. Все работы с null могут происходить только на низком или платформозависимом уровне. Для веб-приложения с его передачей данных по HTTP как раз идеологически противно на уровне модели использовать null.

Или я не понял о чём речь или в корне не согласен. NULL везде полезен.

$storage->findById(16); // Что вернуть в случае отсутсвия в хранилище сущности с id = 16? Исключение кидать?

 

[С.]

Что угодно можешь возвращать, отличное от объекта и желательно приводимое к логическому "нет": 0, "", false, null. Здесь как раз не важно, покольку оно локально для данного конкретного метода. В теме говорится о том, что затрагивает архитектурное решение схемы данных приложения.

 

[Sufir]

Что угодно можешь возвращать, отличное от объекта и желательно приводимое к логическому "нет": 0, "", false, null. Здесь как раз не важно, покольку оно локально для данного конкретного метода. В теме говорится о том, что затрагивает архитектурное решение схемы данных приложения.

Ну, пример не удачен, согласен, тут логика двойная, а в топике речь о троичной. Однако я тебя всё же не понял, с какой стати "противно на уровне модели использовать null" и чем его заментиь?

 

[С.]

Во-первых, сама идеlогия языка подталкивает к тому, что 0=="0"==""==" "==null==undefined.
Во-вторых, стратегический важный канал передачи данных HTTP, не позволяет передавать null.

 

[С.]

Есть два разных подхода, два поколения языков:
3-е поколение (Бейсик, Паскаль...): "0"!=0 всегда
4-е поколение (SQL, Informix...): "0"==0 всегда

То есть они изначально диктуют подход.
В 3-ем, чтобы создать какое-то сложно приложение, а не копошиться в битах и адресах памяти, надо надстроить среду, фреймворк, по сути новый язык.
В 4-ом, наоборот, чтобы создать какой-то низкоуровневый модуль надо обратиться к другому языку.

Сила и беда РНР в том, что в нем можно одинаково работать как с 3-им, так и с 4-ым поколением. Только разработчик должен понимать разницу: вот это я пишу "библиотечную" функцию и в ней я привлекаю nullы-шмуллы, ===, isset() и все что душе угодно. А вот здесь у меня высокуровневая бизнес-логика, все сравнения нестрогие, null -- побоку. Тот, кто кричит о говноязыке или требует строгой типизации для РНР, просто недопонимает разницы в подходах. Еще одно доказательство, что слишком много свободы, может быть вредно.

 

[Redjik]

С.
Ну это очередная теория... и мне нравиться обоснование, но!
Даже если представить ситуацию, что мне надо будет через пол года вернуться к этой бд, в плане читаемости - я сразу, глядя на таблицу, пойму что хотел сделать...
А не enum - +1 запрос, чтобы понять, что там... да + на каждое поле... а их в сумме > 60 штук таких (еще раз смотрим яндекс недвижимость...)

Хотя все решают комментарии в бд...

ЗЫ. извиняюсь за стиль изложения, немного под шафе...

 

[С.]

Redjik, если основным твоим аргументом неприменения теории на практике является то, что enum недостаточно мнемоничен, то ты не под шафе, а неадекватно пьян. Проспись!

 

[Absinthe]

Во-вторых, стратегический важный канал передачи данных HTTP, не позволяет передавать null.

А еще нельзя передавать не только null, то и объект типа User или OrderItem. И что? После этого модель не должна иметь члены такого типа?

Есть два разных подхода, два поколения языков:
3-е поколение (Бейсик, Паскаль...): "0"!=0 всегда
4-е поколение (SQL, Informix...): "0"==0 всегда

PHP является 3GL по определению. Если хочешь опровергнуть - то с источниками.

 

[С.]

Absinthe, ты тоже под шафе?

 

[Ragazzo]

С.
Правильна говорить не под шафе, а "встретился с Духовность"

 

[Absinthe]

Ragazzo а ты то что с ним согласен?

 

[Фанат]

"подшофе", чюрка нерусский ;-)