Паттерны программирования и PHP

Цитата ("raznomir"):

Ну хорошо, давайте не будем обсуждать.

Я там немножко дописал...

Цитата ("tvv"):

На основании чего именно Вы заявляете, что я ничего не знаю? Отвечайте пожалуйста за Ваши слова.

Я могу аргументировать. Но Вы первый должны ответить за свои слова. Или то было голословное утверждение?

Цитата ("elosoft"):

Представьте простейшую ситуцию - имя нового поля совпало и именем таблицы...

Ну и что? Разве это проблема?
Более того, в данном случае запросы же не от фонаря пишутся, а вполне контролируемо. Названия полей четко определены: некий префикс плюс код нового метода доставки. Каким образом там это может случиться?

Цитата ("raznomir"):

Я могу аргументировать. Но Вы первый должны ответить за свои слова. Или то было голословное утверждение?

Нет, не голословное. Я готов ответить.
Более того, я уже ответил, и при этом привел перечень недостатков Вашего решения.
Вы это практически не прокомментировали (точнее, прокомментировали нечетко, я задал уточняющие вопросы, и Вы от ответов на них уклонились, и начали обсуждать мой профайл).

В частности, я с большой степенью вероятности могу быть уверен, что Вы не до конца представляете себе, зачем нужна нормализация при проектировании БД.
Какие существуют нормальные формы, для чего это вообще нужно.
Применяя решение, которое Вы предлагаете Вашим заказчикам, Вы отвергаете фундаментальные основы проектирования баз данных.
Именно поэтому я написал то, что написал, про свои рекомендации заказчикам.

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

Но это потом, пока что я жду ответов на мои вопросы по задаче, на которые Вы не ответили.

Цитата ("tvv"):

Я задал Вам вопросы по Вашему же примеру и по Вашим же утверждениям, Вы не ответили.

Я ответил. Если Вас мои ответы не устраивают, это не мои проблемы

Цитата ("tvv"):

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

Я достаточно ясно понимаю, что такое нормализация, и зачем ее требовали раньше. И я вполне ясно и сознательно определил отсутствие жесткой необходимости полной нормализации сейчас. Почему - я тоже объяснил ранее.

Цитата ("tvv"):

Вы отвергаете фундаментальные основы проектирования баз данных.

Это я тоже уже объяснял - Вы немножко не в курсе последних решений партии.

Цитата ("tvv"):

И обратите внимание, на личности я не переходил, и плохими словами Вас не называл, а лишь указал на пробел в знаниях.

Аналогично.
Более того, Ваших заказчиков я не трогал.

И все же, Вы не ответили. Я повторю вопросы.

Цитата ("raznomir"):

Пункты 1, 3 и 5 Вашего списка важных принципов организации БД элементарно выдерживаются и в иных вариантах реализации, а не только "канонических".

Не принимается. Это общие слова.
Можете ли написать, по каждому из пунктов 1, 3 и 5, как именно это выдерживается в Вашем варианте с таблицей с кучей колонок?

Цитата ("raznomir"):

Пункт 2 и 4 - уже не вижу смысла выдерживать, более того, если Вы почитаете другие умные книжки (поновее), а также подключите и логическое мышление, то обнаружите, что правильно построенная избыточность и дублирование данных как раз повышает надежность и целостность БД, а также скорость работы с ней.

"Умные книжки поновее" — это что? Приведите пожалуйста пример.
Далее. Подключив логическое мышление, как Вы мне советуете, я так и не обнаружил, как именно избыточность и дублирование NULL значений в Вашем примере могут повысить "надежность и целостность".
Вы же только пустые места размножили в своих колонках, но никак не данные о цене по региону.

Можете пожалуйста это прокомментировать?

Цитата ("raznomir"):

Я ответил. Если Вас мои ответы не устраивают, это не мои проблемы

Дайте, пожалуйста, ссылочку на хотя бы частично вменяемый и адекватный ответ, который вы тут давали. Точно на этом форуме?

Пока что все ваши ответы как в анекдоте:

Цитата ("raznomir"):

Я могу аргументировать. Но Вы первый должны ответить за свои слова. Или то было голословное утверждение?

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

Цитата ("tvv"):

Можете ли написать, по каждому из пунктов 1, 3 и 5, как именно это выдерживается в Вашем варианте с таблицей с кучей колонок?

А может наоборот? Аргументируйте, каким образом в моем варианте НЕ выдерживаются пункты 1, 3 и 5? Где там ненадежность? Где целостность страдает? Где Вы там увидели запрет на расширение?

Цитата ("tvv"):

"Умные книжки поновее" — это что? Приведите пожалуйста пример.

А гугл Вас уже забанил?

Цитата ("tvv"):

Далее. Подключив логическое мышление, как Вы мне советуете, я так и не обнаружил, как именно избыточность и дублирование NULL значений в Вашем примере могут повысить "надежность и целостность".
Вы же только пустые места размножили в своих колонках, но никак не данные о цене по региону.

А с чего вдруг Вы привязали одно к другому? Я говорил, что избыточность и дублирование в целом могут повысить надежность и целостность, но никак не конкретно в связи с моим примером. В моем примере на это избыточность никак не влияет - ни увеличивает и не уменьшает.
Конкретно в моем примере избыточность была необходима для повышения скорости запроса.

Цитата ("tvv"):

Итак, я ответил.

Вот что-то не заметил ответа.

Цитата ("tvv"):

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

А на каком основании Вы утверждаете о пробеле в моих знаниях БД?
Может быть знаете какие-то случаи, где я кому-то давал ламерские советы по БД? Или кто-то из моих заказчиков жаловался?

Цитата ("raznomir"):

А может наоборот? Аргументируйте, каким образом в моем варианте НЕ выдерживаются пункты 1, 3 и 5? Где там ненадежность? Где целостность страдает? Где Вы там увидели запрет на расширение?

Разве Вы не заметили? вот еще подтверждение Вашего невладения вопросом. По пунктам:

Ненадежность. Я же написал (Вы это читали?) DDL операции не откатываются транзакционным движком при сбое (MS SQL не рассматриваем). То есть, при сбое на этапе изменения схемы данных Вы вынуждены будете вернуться к бакапу, восстановление из которого может быть чревато для живого проекта потерей последних данных.

Целостность. Надеюсь, Вы знаете что это? Я же написал (Вы это читали?) что Ваше решение не гарантирует целостности. То есть, вполне может быть удален метод доставки из таблицы методов доставок, но при этом может остаться колонка в таблице регионов. Или наоборот, может быть добавлен новый метод доставки, но не добавлена соответствующая ей колонка. При этом средствами базы данных Вы не можете гарантировать отсутствие мусора (значений, на которые ничто не ссылается) или наоборот отсутствующих значений.

Расширяемость. Я же написал (Вы это читали?) пример, если например заказчик пришлет новое требование, добавить не только метод доставки для региона, но еще и время доставки. Еще один параметр. Что Вы будете делать, добавлять еще кучу колонок в таблицу регионов для времени для каждого метода доставки, с префиксом, или все же добавите новую таблицу? В то-то и проблема вашего решения, что оно очень негибкое, требующее кардинальных переделок в случае расширения функциональности (кстати, в теории СУБД это один из важных аргументов необходимости нормализации).

Цитата ("raznomir"):

А гугл Вас уже забанил?

Гугл не забанил. Но я просто не знаю что искать в гугле, так как Вы мне этого не сообщили. Вы говорили про какие-то новые книги, но какие именно? Пока Вы не дадите ссылок (или хотя бы названий) я склонен считать, что Вы это придумали.

Цитата ("raznomir"):

Конкретно в моем примере избыточность была необходима для повышения скорости запроса.

Вы уверены, что скорость запроса будет выше на величину, которую сможет зафиксировать профайлер? (скорее всего, счет идет на микросекунды)
Но даже если и так, насколько часто выполняете такой запрос?
В идеале, он должен выполняться один раз после последнего изменения данных, а потом результат будет размещен в кеше. Если у вас это реализовано не так, то это тоже повод задуматься...

Цитата ("raznomir"):

Вот что-то не заметил ответа.
..........
А на каком основании Вы утверждаете о пробеле в моих знаниях БД?
Может быть знаете какие-то случаи, где я кому-то давал ламерские советы по БД? Или кто-то из моих заказчиков жаловался?

Я сделал этот вывод на основании Вашего решения с таблицей регионов с кучей колонок для каждого метода доставки, которое Вы предоставляете Вашим заказчикам.
Дальнейшее обсуждение вопроса на этом форуме подтвердило мои сомнения в пробелах в Ваших знаниях.

Особенно Ваши выражения вида "зачем ее требовали раньше", "отсутствие жесткой необходимости полной нормализации сейчас" говорят не в Вашу пользу. Например, выражение "полная нормализация" применяется в медицине и политике, но к базам данных не имеет никакого отношения.

Еще, про безопасность. Чтобы Ваш метод с добавлением колонок работал, необходимо, чтобы у пользователя БД были права на DDL операции.
То есть вместо того, чтобы дать пользователю лишь минимум прав, и лишь на DML операции к некоторым таблицам, Вам придется давать ему еще и права на изменение схемы данных... А это уже не хорошо с точки зрения безопасности.

Мне очень жаль, но Ваше решение действительно не выдерживает никакой критики, и мне странно, что Вы его защищаете.
Если бы Вы сразу признали это решение недостаточно корректным, то и с моей стороны небыло бы сомнений в Вашей компетенции как разработчика (обратите внимание, я не называю Вас некомпетентным, а лишь высказываю сомнение, на основании Ваших же утверждений).

Пожалуйста, без обид. Но Вы сейчас спорите не со мной, а с фундаментальной теорией, которую отвергли.

Цитата ("tvv"):

DDL операции не откатываются транзакционным движком при сбое. То есть, при сбое на этапе изменения схемы данных Вы вынуждены будете вернуться к бакапу

Да с чего вдруг такой вывод? И А здесь совершенно не следует Б.

Цитата ("tvv"):

То есть, вполне может быть удален метод доставки из таблицы методов доставок, но при этом может остаться колонка в таблице регионов. Или наоборот, может быть добавлен новый метод доставки, но не добавлена соответствующая ей колонка. При этом средствами базы данных Вы не можете гарантировать отсутствие мусора (значений, на которые ничто не ссылается) или наоборот отсутствующих значений.

А кроме как средствами самой базы данных, Вы иных вариантов не знаете?

Цитата ("tvv"):

Расширяемость. Я же написал (Вы это читали?) пример, если например заказчик пришлет новое требование, добавить не только метод доставки для региона, но еще и время доставки. Еще один параметр. Что Вы будете делать, добавлять еще кучу колонок в таблицу регионов для времени для каждого метода доставки, с префиксом, или все же добавите новую таблицу? В то-то и проблема вашего решения, что оно очень негибкое, требующее кардинальных переделок в случае расширения функциональности (кстати, в теории СУБД это один из важных аргументов необходимости нормализации).

Если появится такое требование, это значит, что данный процесс перейдет на более сложный уровень представления данных, и преспокойно переделаем структуру. Что вас всех так пугает изменение структуры БД? Или Вы можете 100%-но гарантировать, что Ваши решения никогда не потребуют дополнений? И если сначала заказчик хотел просто чтобы пользователь выбрал отдельно метод доставки и регион доставки, а потом вдруг надумал, чтобы еще и сразу стоимость считать, то создание третьей таблицы не будет считаться переделкой?

Цитата ("tvv"):

Но я просто не знаю что искать в гугле, так как Вы мне этого не сообщили. Вы говорили про какие-то новые книги, но какие именно? Пока Вы не дадите ссылок (или хотя бы названий) я склонен считать, что Вы это придумали.

По ключевым словам ищите, мне ли Вас учить? Это же не одна какая-то конкретная книга, чтобы я дал название и прямо ссылку, это уже лет десять как ищет изменение взгляда на организацию БД.

Цитата ("tvv"):

Я сделал этот вывод на основании Вашего решения с таблицей регионов с кучей колонок для каждого метода доставки, которое Вы предоставляете Вашим заказчикам.
Дальнейшее обсуждение вопроса на этом форуме подтвердило мои сомнения в пробелах в Ваших знаниях.

Разве что несоответствие моих знаний Вашим знаниям, что никак не эквивалентно наличию пробела в моих знаниях. И если быть точным, то решение было как раз с кучей колонок для каждого региона, а не метода, Вы невнимательно читали.

Цитата ("tvv"):

Чтобы Ваш метод работал, с добавлением колонок, необходимо, чтобы у пользователя БД были права на DDL операции.
То есть вместо того, чтобы дать пользователю лишь минимум прав, и лишь на DML операции к некоторым таблицам, Вам придется давать ему еще и права на изменение схемы данных... А это уже не хорошо с точки зрения безопасности.

О, и Вы туда же. Может, хоть Вы мне сможете объяснить, чем именно это чревато?

Цитата ("tvv"):

Мне очень жаль, но Ваше решение действительно не выдерживает никакой критики, и мне странно, что Вы его защищаете.

Да критика какая-то слабенькая... Настолько мало конкретных возражений, что Вам приходится привлекать на помощь авторитетную мощь фундаментальной теории и постоянные голословные обвинения в моей некомпетентности. Чтобы усилить эффект.

Цитата ("raznomir"):

Цитата (tvv):
DDL операции не откатываются транзакционным движком при сбое. То есть, при сбое на этапе изменения схемы данных Вы вынуждены будете вернуться к бакапу

Да с чего вдруг такой вывод? И А здесь совершенно не следует Б.

Ну как же. Как раз в данном случае следует.
Как в Вашем проекте происходит например добавление нового метода доставки?
Наверняка Ваша админка делает две операции, а именно 1) создает новую запись в таблице методов доставок и 2) добавляет новую колонку в таблицу регионов. Или операции 1 и 2 выполняются наоборот.
Так вот, что произойдет, если после операции 1 по какой-то причине не выполнится операция 2? В Вашем случае необходимо будет или ручное вмешательство, или же писать много дополнительного кода (так же ненадежного) по отслеживанию таких ситуаций.
В то время как в случае с DML операциями транзакционный движок все откатит обратно.

Цитата ("raznomir"):

А кроме как средствами самой базы данных, Вы иных вариантов не знаете?

Других простых и надежных вариантов я действительно не знаю. Потому что я не знаю того, чего нет.
Можно вместо этого написать кучу кода для проверки целостности, но это будет ни просто в реализации, ни надежно (даже в случае самой лучшей реализации в коде).

Цитата ("raznomir"):

По ключевым словам ищите, мне ли Вас учить? Это же не одна какая-то конкретная книга, чтобы я дал название и прямо ссылку, это уже лет десять как ищет изменение взгляда на организацию БД.

Понятное дело что что-то новое добавляется, прогресс не стоит на месте. Но чтобы что-то кардинально изменилось, так это вряд ли, по крайней мере это было бы на слуху, и я бы знал (это моя профессия).

Если Вы знаете такие источники, почему не хотите поделиться хотя бы ссылками и названиями?
Я таких источников не знаю, и об "изменение взгляда на организацию БД" тоже ничего не знаю. И не знаю даже по каим ключевым словам искать, если бы знал, то не спрашивал бы.
Учитывая, что Вы ссылок не даете, я склонен сомневаться в существовании таких источников.

Цитата ("raznomir"):

О, и Вы туда же. Может, хоть Вы мне сможете объяснить, чем именно это чревато?

Чем чревата постоянная работа с рутовыми правами?
Аналогично и тут, работая с высокими привилегиями повышается риск понести более серьезные потери в случае несанкционированного доступа (например через SQL инъекцию).

Мне очень печально видеть Ваши подобные вопросы...

Цитата ("tvv"):

Наверняка Ваша админка делает две операции, а именно 1) создает новую запись в таблице методов доставок и 2) добавляет новую колонку в таблицу регионов. Или операции 1 и 2 выполняются наоборот.
Так вот, что произойдет, если после операции 1 по какой-то причине не выполнится операция 2? В Вашем случае необходимо будет или ручное вмешательство, или же писать много дополнительного кода (так же ненадежного) по отслеживанию таких ситуаций.
В то время как в случае с DML операциями транзакционный движок все откатит обратно.

В данном случае сначала добавляется запись в таблице методов. И даже если произойдет сбой при добавлении колонки, это не страшно. Ибо при правильном построении работы, отсутствие колонки далее в нужном месте вызовет ее создание. А именно, при загрузке админом в следующий раз на редактирование регионов/методов. А до этого, при отсутствии колонки, данный метод для всех регионов будет считаться недоступным (как и в тех случаях, когда в ячейке стоит NULL, кстати - так что даже и избыточности тут нет, это я что-то увлекся). Где здесь ручное вмешательство или много дополнительного ненадежного кода? Где здесь нарушение целостности? На всякий случай еще раз подчеркну, что внутренней логикой базы как раз и подразумевается, что если нет колонки, то метод недоступен. Так что даже формально не придеретесь.

Цитата ("tvv"):

Других простых и надежных вариантов я действительно не знаю. Потому что я не знаю того, чего нет.

Вы и правда на полном серьезе считаете, что если Вы чего-то не знаете, то этого не существует?

Цитата ("tvv"):

Понятное дело что что-то новое добавляется, прогресс не стоит на месте. Но чтобы что-то кардинально изменилось, так это вряд ли, по крайней мере это было бы на слуху, и я бы знал (это моя профессия).

Я рад, что у Вас такая высокая самооценка. И все-таки, поищите в гугле по ключевому слову "Денормализация". Вдруг чего нового для себя узнаете.

Цитата ("tvv"):

Чем чревата постоянная работа с рутовыми правами?
Аналогично и тут, работая с высокими привилегиями повышается риск понести более серьезные потери в случае несанкционированного доступа (например через SQL инъекцию).

Я разве предлагал работать под рутом???
В-общем, все ясно... пока идет разговор на абстрактном уровне - у Вас есть куча умных слов и знаний терминов. А конкретнее можете написать? В чем риск? Пример хотя бы один? Я выше у elosoft это спрашивал уже - он предпочел уйти от разговора просто.

Эх, удалил пост случайно.
Вы хоть имеете представление о том, что NULL также занимает место и наличие кучи ненужных полей в таблице требует больше ресурсов и просто напросто делает из таблицы простыню?

Цитата ("Lisio"):

Вы хоть имеете представление о том, что NULL также занимает место и наличие кучи ненужных полей в таблице требует больше ресурсов и просто напросто делает из таблицы простыню?

Вам особо повторить?
1. Избыточность принимается осознанно в пользу повышения производительности. Вам места на винте мало?
2. В данном случае даже избыточности нет, ибо NULL обозначает недоступность данного метода доставки в данный регион.

Цитата ("raznomir"):

Где здесь нарушение целостности? На всякий случай еще раз подчеркну, что внутренней логикой базы как раз и подразумевается, что если нет колонки, то метод недоступен. Так что даже формально не придеретесь.

К сожалению, придерусь. А именно, и теперь я уже в этом уверен, Вы не знаете, что такое целостность данных.
Я уже дважды привел Вам пример нарушения целостности при Вашей схеме, и Вы это проигнорировали.

Еще раз, если возможна ситуация, когда в базе данных могут находиться данные, на которые ничто не ссылается и которые не используются, или наоборот могут быть ссылки на несуществующие данные, то это — прямое нарушение целостности. В Вашей схеме это возможно. Вы пытаетесь этого избежать, написав код для мониторинга, но это кривой костыль по определению, ибо выполняется из другой подсистемы, к тому же, избыточно не нужный костыль, если данные в БД были бы организованы правильно.

Цитата ("raznomir"):

Я рад, что у Вас такая высокая самооценка. И все-таки, поищите в гугле по ключевому слову "Денормализация". Вдруг чего нового для себя узнаете.

Этому слову столько же лет, столько и слову нормализация.
Более того, принципы денормализации были сформированы в то же самое время, что и принципы нормализации, и теми же самыми теоретиками, и с тех пор практически не изменялись. И я использую это в проектах моих клиентов там, где это действительно уместно, причем последние лет 15. Также, я говорил о денормализации в моем сообщении к Вам от 16:54 (посмотрите пункт 4).

Итак, где же тут якобы новое "изменение взгляда на организацию БД" (c) ?

Цитата ("raznomir"):

Я разве предлагал работать под рутом???
В-общем, все ясно... пока идет разговор на абстрактном уровне - у Вас есть куча умных слов и знаний терминов. А конкретнее можете написать? В чем риск? Пример хотя бы один?

Вы предложили аналогичное решение, что и работать под рутом.
А именно, получать доступ к БД пользователем с высоким уровнем привилегий (ибо иначе не получится проводить DDL операции), вместо того, чтобы дать лишь возможность производить DML операции.
Вам действительно нужен конкретный пример, чтобы показать, чем это плохо давать пользователю БД высокие привилегии, Вы действительно этого не понимаете?

Мне не хотелось бы продолжать этот разговор, ибо боюсь что бесполезная трата времени. Хотя вначале я действительно хотел помочь Вам разобраться, но получил от Вас лишь оскорбления в свой адрес что, мол, я ничего не знаю, что в моем профайле написана чушь и т.д. Ну ладно. Жаль только начинающих ребят, которые эту тему могут читать, и затем не подумав использовать какое-либо из Ваших предложений на практике. Потому и продолжаю.

Цитата ("raznomir"):

1. Избыточность принимается осознанно в пользу повышения производительности. Вам места на винте мало?

Ну и храните тогда цены в blob, ну серьезно, вам места что ли жалко на винте? Да справится процессор, не переживайте.
О каком повышении производительности речь? Весь выигрыш в скорости от наличия всех цен в одной таблице просто раздавится под весом возросшей нагрузки от увеличения длины каждой записи в этой таблице.

Цитата ("raznomir"):

2. В данном случае даже избыточности нет, ибо NULL обозначает недоступность данного метода доставки в данный регион.

А это извините, полный ахтунг. Вы всегда храните информацию о том, что недоступно? То есть вы заказчикам дырки от бублика в базу пихаете?

Ладно, теперь по делу о вашем примере. Допустим, админ заходит в раздел добавления методов доставки. Создает новый. В одну таблицу добавился новый метод доставки, в таблицу регионов не добавился (ну бывает, запроса-то два). Админ не замечает подвоха, идет спать. Скрипт ваш супер-корректорский не запускается, так как админ спит аки принцесса. Заходит посетитель на сайт, выбирает доставку в регион, нажимает рассчитать и ... тоже идет спать, т.к. метод доставки есть, а поля такого в базе нет, и даже NULL взять неоткуда, и система рассчетов накрылась медным тазом. Ах, да, надо же и тут костыли поставить. Ну что же, успехов вам в создании инет-магазина по продаже костылей. А ведь казалось бы, база могла исключить такие косяки сама, но нет, чхать мы хотели на нее.

Цитата ("raznomir"):

В данном случае сначала добавляется запись в таблице методов. И даже если произойдет сбой при добавлении колонки, это не страшно. Ибо при правильном построении работы, отсутствие колонки далее в нужном месте вызовет ее создание. А именно, при загрузке админом в следующий раз на редактирование регионов/методов. А до этого, при отсутствии колонки, данный метод для всех регионов будет считаться недоступным (как и в тех случаях, когда в ячейке стоит NULL, кстати - так что даже и избыточности тут нет, это я что-то увлекся). Где здесь ручное вмешательство или много дополнительного ненадежного кода?

В этом случае ручное вмешательство действительно не обязательно, если админ обязательно (!) будет заходить в форму редактирования регионов/методов после сбоя. Конечно, если Вы написали корректный код для мониторинга БД, и он будет выполняться.

А можете ли написать сценарий, что будет при удалении метода доставки? Если удалите метод доставки, и произойдет сбой, а колонка не будет удалена. При следующем заходе админа на редактирование это будет проверяться? То есть, метода доставки нет, а колонка есть? Если да, то как Вы это делаете, подгружаете метаданные талицы для определения колонок, и выбираете те из них, которые имеют нужный Вам префикс? (другого способа не вижу, но даже это, с метаданными — кривой ламерский костыль).

И еще. Значение NULL все же занимает место. И NULLABLE поля обрабатываются движком базы данных медленнее, чем NOT NULL поля, ибо в этом случае используется другая логика (ряд дополнительных правил, похожих на правила троичной логики).