Здравствуйте, -n1l-, Вы писали:
N>Есть две таблицы, связанные один к одному. N>Как например офис и город. N>Предполагается, что офис может быть либо в одном городе либо во всех городах.
N>Решение, сделать fk = null для офиса который расположен во всех городах и fk = value для офиса в одном городе. N>Как вам?
Не выйдет. FK всегда ссылается на PK, а PK не может содержать NULL. Я рекомендую использовать ID = 0 (All)
Здравствуйте, Milena, Вы писали:
M>Не выйдет. FK всегда ссылается на PK, а PK не может содержать NULL. Я рекомендую использовать ID = 0 (All)
Ай ну короче это самопильный черезжопный FK, он может быть null
Мне нужны доводы, что бы переубедить.
И если я правильнео понял, вы предлагаете все таки делать какое-то значение, что бы однозначно идентифицировать "все города"?
Limitations and Restrictions
A table can contain only one PRIMARY KEY constraint.
All columns defined within a PRIMARY KEY constraint must be defined as NOT NULL. If nullability is not specified, all columns participating in a PRIMARY KEY constraint have their nullability set to NOT NULL.
Здравствуйте, -n1l-, Вы писали:
N>Решение, сделать fk = null для офиса который расположен во всех городах и fk = value для офиса в одном городе. N>Как вам?
А как это будет использоваться?
Искать офисы в заданном городе не потребуется? А если потребуется, то как вы будете это делать?
А во вторых потому что система имеет неприятное свойство развиваться со временем. Через какое-то время окажется что офис уже планируется, а с городом ещё не вполне определились (и для данного случая как раз потребуется NULL во внешнем ключе, который вы уже таким нестандартным способом задействовали) и/или что таки есть такие офисы, которые таки в нескольких городах, но не во всех.
Поэтому сделать, конечно, можно как угодно, но я бы лично остерёгся использовать такое нестандартное решение.
Здравствуйте, -n1l-, Вы писали:
N>Решение, сделать fk = null для офиса который расположен во всех городах и fk = value для офиса в одном городе. N>Как вам?
Во-первых, "офис во всех городах" — это нечто не соответствующее реальности. Это мешает хорошему ответу, поскольку рождает противоречие между имеющимся опытом и требованиями задачи. Лучше давайте реальную задачу, шанс разумного ответа гораздо выше.
Во-вторых, с точки зрения красоты схемы лучше развернуть fk, сделать его из городов в офисы. Тогда исчезнет причина Вашего вопроса. Но чтобы советовать или не советовать так сделать, нужно посмотреть реальную задачу — например, так не стоит делать, если в будущем в одном городе может появиться несколько офисов.
В целом такое решение допустимо, но коряво. Для студенческой работы сойдёт (хотя зависит от препода), для реальной — вызывает ощущение, что по мере развития задачи и уточнения требований придётся переделать.
S> Ужасно -- это не реляционный подход. У Вас связь один-ко-многим, вот и делайте ее.
У него не связь один ко многим. Разница в том, что в его задаче при появлении нового города он автоматом начнёт обслуживаться офисом "на все города", при связи же один ко многим — нет.
M> Не выйдет. FK всегда ссылается на PK, а PK не может содержать NULL.
Столь бредовое поведение, насколько я в курсе, было характерно только для древних версий Interbase. Если вдруг где-то такое не выйдет, лучшее, что можно сделать — снести ту фекалию мамонта, в которой не вышло, и использовать вместо неё СУБД.
M> Я рекомендую использовать ID = 0 (All)
Вот сослаться через FK на отсутствующую запись с id = 0 действительно не выйдет в большинстве СУБД, придётся вставлять левый город "Все" с id = 0. А этот подход — охрененной производительности генератор сложных багов в production обстановке. Такие ошибки склонны проходить этап тестирования и спустя продолжительное время "стрелять" у пользователя. Я в своей практике имел дело с единственной системой, выполненной в подобной архитектуре, и из всех проблем, которые пришлось решать, минимум треть — причём, самая гадская треть — была следствием именно этого трям-трям-трям очень умного решения.
Здравствуйте, -n1l-, Вы писали:
N>Есть две таблицы, связанные один к одному. N>Как например офис и город. N>Предполагается, что офис может быть либо в одном городе либо во всех городах.
N>Решение, сделать fk = null для офиса который расположен во всех городах и fk = value для офиса в одном городе. N>Как вам?
Ваше решение вполне может быть жизнеспособным и решать поставленную задачу, но чтобы дать ему правильную оценку необходимо понять, а какая собственно задача решается. У меня это решение вызывает некоторые сомнения:
1. Вообще Null означает отсутствие данных
2. Значение Null идентичное значению "Все города" совершенно не очевидно для остальных разработчиков. Хотя возможно ваша система хорошо документируется и преемственность кода не является проблемой.
3. А как собственно писать запросы к такой схеме, т.е. соединять данные? Необходимо будет оборачивать Null значение, использовать ИЛИ в условиях поиска, как результат — возможно неэффективное построение плана запроса, parameter sniffing, пропуск индексов и т.п. Хотя возможно у вас там всего 20 значений и о больших объемах речи не идет.
4. Как правильно заметили выше, данный поход создает проблему роста. Т.е. возможно завтра у вас требования изменятся и необходимо будет хранить офисы, которые пока не расквартированы по городам.
Здравствуйте, Milena, Вы писали:
M>Не выйдет. FK всегда ссылается на PK, а PK не может содержать NULL. Я рекомендую использовать ID = 0 (All)
Дело в том, что между сущностями может существовать связь, но каждый экземпляр одной сущности может быть ассоциирован с произвольным количеством экземпляров другой сущности, в том числе с нулевым.
В таблице офисов, автор не заполняет FK для города, т.е. оставляет его равным null. При этом таблица городов у него заполнена и для каждой записи есть свой PK конечно не равный null. Формально — это отношение один к нулю или одному (1-0...1), т.е. когда дочерняя сущность является не обязательной и может не существовать, при этом родительская всегда существует.
Ну если вместо PK создать UNIQUE CLUSTERED INDEX с NULL value, и на него направить FK, а также отдельно создать некий фэйковый PK, который будет NONCLUSTERED, то это, конечно, будет офигенно круто
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, -n1l-, Вы писали:
N>>Решение, сделать fk = null для офиса который расположен во всех городах и fk = value для офиса в одном городе. N>>Как вам?
M>> Я рекомендую использовать ID = 0 (All)
S>Вот сослаться через FK на отсутствующую запись с id = 0 действительно не выйдет в большинстве СУБД, придётся вставлять левый город "Все" с id = 0. А этот подход — охрененной производительности генератор сложных багов в production обстановке. Такие ошибки склонны проходить этап тестирования и спустя продолжительное время "стрелять" у пользователя. Я в своей практике имел дело с единственной системой, выполненной в подобной архитектуре, и из всех проблем, которые пришлось решать, минимум треть — причём, самая гадская треть — была следствием именно этого трям-трям-трям очень умного решения.
Я собственно рекомендовала просто не использовать NULL, и если уж ставить грабли, то хотя бы сделать фэйковое числовое значение, чтобы не морочить голову обработкой NULL и проблемами с PK.
Я согласна с тем, что это не оптимальное решение, но иногда, если таблица используется ТОЛЬКО для репортов, это будет работать быстрее. Если таблица используется повсеместно, то лучше изначально сделать грамотный дизайн с нормальными ключами и приложение, которое будет эти ключи правильно обновлять.
When a value other than NULL is entered into the column of a FOREIGN KEY constraint, the value must exist in the referenced column; otherwise, a foreign key violation error message is returned.
M>Не выйдет. FK всегда ссылается на PK, а PK не может содержать NULL.
Здравствуйте, -n1l-, Вы писали:
N>Предполагается, что офис может быть либо в одном городе либо во всех городах.
А "офис во всех городах" это как? Может "офис на все города"?
N>Решение, сделать fk = null для офиса который расположен во всех городах и fk = value для офиса в одном городе. N>Как вам?
