Какое ваше отношение к таблицам с внешним ключам с NULL значением?

Question

[ooooooooooooooo]

Привет! На картинке есть структура связей между моделями, задача простая.
Пользователю нужно выбрать страну, регион и город. Количество не ограничено, может выбрать к примеру 3 страны, 5 регионов и 10 городов.
Или выбрать только города, в этом случае столбцы Country и Subject будут иметь NULL.
Таблица LOCATIONS будет использована в выборке для рассылки EMAIL-сообщений и в фильтрах поиска на сайте
В интернете мнение расходятся, кто-то ЗА такой подход, кто-то ПРОТИВ, хотел бы узнать Ваше мнение

Comments

[N]

В интернете мнение расходятся, кто-то ЗА такой подход, кто-то ПРОТИВ, хотел бы узнать Ваше мнение

А "мы" - разве не интернет? :)
Думаю, что мнения так же - "разойдутся"...))

Answer 1

[Mylistryx]

А я за NULL! При ForeignKeys - корректное поведение, при unique - корректное поведение, при JOIN корректное поведение.
FK позволяют организовать целостность данных на уровне БД (CASCADE/RESTRICT/ SET NULL -это уже от бизнес логики) и там нет ON DELETE SET 123 или ON DELETE SET 0, что говорит само за себя, как и NULL значения при LEFT JOIN.
unique (column):
null
null
1
2
...
- и это нормальное и правильное поведение, т.е. значения уникальны, если они указаны. С 0 или суррогатным значением так не выйдет и будет расти еще один костыль.
По поводу экономии места - в нынешних реалиях, экономия на спичках.
Про обработку NULL / NOT NULL -если используется ORM либо обертка какая, то там это обычно реализовано прозрачно. К примеру Yii2: ArModel::findOne(['col' => null]) само развернет в нужный SQL код. В других фреймворках думаю тоже.
P.S. Имею ввиду MySQL, в других БД возможно по другому.

Answer 2

[N]

Вот, по-моему мнению, что должно быть главным критерием при проектировании структуры в данном случае:

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

P.S.: Вам больше место жалко или производительность? :)

P.S.S.: Чем не устраивает 0 вместо NULL для чисел?

P.S.S.S.: В запросах один фиг будет фигурировать либо "IS NULL/NOT NULL", либо "<> 0"...заморочки одни и те же по сути...а вот разница в этом всём как - "лысый" и "бритый" :)

P.S.S.S.S.: Есть негласное правило...

NULL нафиг не нужен, если все его свойства не используются...

А вот какие оно имеет свойства:

Если вы сравниваете значение NULL с другим значением NULL или любым другим значением, результатом является то, что значение NULL каждого значения NULL неизвестно. Обычно значение NULL используется для указания того, что данные отсутствуют, неизвестны или неприменимы.

Но в данном случае у Вас по значению 0 и так будет понятно всё.

Вопрос: нафиг этот NULL ? Все его "плюсы" в данном случае не работают...

Ну и вот уже было тут:
https://qna.habr.com/q/463917

Выбор зависит от задач(и)...

Comments

[ooooooooooooooo]

а разве не будет возникать конфликт? ведь если указывается числовое значение, то оно должно ссылаться на id существующей записи

[Василий Дёмин]

ooooooooooooooo, Будет, если есть внешний ключ

[N]

ooooooooooooooo, Вы про inner/left join ?
Так в самом запросе, что при NULL, что при 0 придётся это "разруливать" один фиг...

[Василий Дёмин]

N, Если добавить внешний ключ на поле, то ноль вставить субд не даст, потому что записи с таким id не существует. Не добавлять внешний ключ на поле, где он должен быть, чтобы вместо NULL использовать 0, - такая себе идея

[ooooooooooooooo]

Мне уже кажется, что лучше создать промежуточные талицы по типу COUNTRY_USER,
SUBJECT_USER и CITY_USER
пусть грамозко, но практичней

[N]

Василий Дёмин, Так тут палка о "двух концах"...коммент мой смотрите под вопросом автора :)

Сейчас все тут поспорят...а по итогу мы тут не нужны... :)
Автору вопросу виднее для его задачи потребности...

[N]

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

[ooooooooooooooo]

N, :D но тем не менее, к примеру нижний ответ, для меня оказался интересным и полезным

[N]

ooooooooooooooo, Какой именно ответ? О том, что у страны не может быть регионов, а у регионов - городов? :)
Так это вообще не про NULL :)

[Vitsliputsli]

Использование null никак не поможет сохранить место, наоборот nullable столбец будет занимать чуть больше места.
Индекс по null также строится и с производительностью там не будет никаких проблем.
В общем технически, разницы практически нет.
Бизнесово, группируя, например, по country_id нужно исключать из выборки фейковую страну 0. Не говоря уже о foreign keys. Вообще прописывать в каждой выборке еще и исключения, сомнительная затея.

[N]

Vitsliputsli, Я вообще за такой вариант - к чему сам автор и пришёл:

Мне уже кажется, что лучше создать промежуточные талицы по типу COUNTRY_USER,
SUBJECT_USER и CITY_USER
пусть грамозко, но практичней

[Vitsliputsli]

N, да, это будет универсальнее и во многих случаях удобнее. Если не брать в расчет, что с объектами географическими все сложнее (то что mayton2019 описал). А вот по скорости это решение будет проигрывать (все таки 3 запроса, вместо 1го)

Answer 3

[mayton2019]

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

В разных странах и государствах после уровня страны например не всегда идут города или области. Там могут
быть более сложные объекты (федеральные земли, периферии). И хуже того они могут стоять на разных уровнях. Улицы одного города могут внезапно иметь двойников (после слияния поселков к примеру). Могут быть улица Ленина, проспект и бульвар и переулок того-же имени.

Вобщем если вы хотите иерархию - то можно делать иерархию. Но нельзя гарантировать жесткую типизацию для какого-то уровня. И с уникальностью - косяки.

Comments

[N]

Это всё понятно...но у автора вопроса другой вопрос: NULL или нафиг его? :)

[ooooooooooooooo]

N, Уже решено, нафиг нал)))