Абсолютно правильная система (идеальная, как идеальный газ):
1. не должна иметь null
2. для ввода первичных данных должен использоваться только insert (никаких update и delete не должно быть вообще в системе)
3. для отчетов и вывода данных использовать только select

В принципе это реализуемо, но на практике не всегда целесообразно

Поясню для непонимающих приколов :-)

1.

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

2.

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

Тоже не менее часто необходимо удалять объекты не физически, а логически, чтобы иметь возможность восстановления записи. Для этого достаточно создать создать таблицу Deleted и помещать туда указатели на удаленные объекты.

3.

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

Я ведь написал, что это в идеале :-)

На практике полностью придерживаться этих правил далеко не всегда целесообразно

--------------------
Не учи отца и баста!

tru55

А знаешь откуда взялся на самом деле null? Его ведь не специально придумали.

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

Table_ID
Column_ID
Row_ID
Value

так вот, если у нас в какой-то ячейке пользовательской таблицы значение null, то это значит, что для этой ячейки нет записи в вышеприведенной таблице и при формировании пользовательской таблицы в этом месте просто получается дыра. Это можно хорошо проследить если поработать с кубами (OLAP). Именно поэтому

--------------------
Не учи отца и баста!

А ведь служащий может быть не к одному отделу приписан. Допустим я в отделе ИТ и при этом мне не хватает денег и я решил подрабатывать техничкой по вечерам, а потом еще и сторожить по ночам :-)

:-)))))))))))))))))))))))))))))))

Бывает конечно, при упрощении модели.

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

--------------------
Не учи отца и баста!

tru55, я не говорю что примеры приведенные Вами нельзя реализовывать. Вполне возможно и допустимо. Просто меня что-то понесло сегодня :-)

--------------------
Не учи отца и баста!

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

--------------------
Не учи отца и баста!