Всем добрый вечер!
Допустим, стоит задача . Есть три таблицы: Дома (условно назовём H ), Квартиры ( F ) и Счётчики ( M ). Дома могут быть как многоквартирными, так и частными. Счётчики могут быть как на отдельную квартиру, так и на весь дом (и частный, и многоквартирный).
Вопрос : Каким образом лучше организовать связи между данными тремя таблицами?
У меня пока созрели два способа:
1. Сквозной искусственный ключ для домов и квартир.
2. Два внешних ключа в таблице Счётчиков M – на дом и на квартиру. Вероятно, с ограничением типа (на XOR не обращайте внимания, это концепт)

P.S. И ещё несколько мелких вопросов по проектированию БД в общем:
1. Как лучше поступать с простыми естественными ключами (такими как серия+номер паспорта, ИНН, ЕГРПОУ и пр.): делать их первичными, или создавать искусственные, а на ЕК вешать уникальность?
2. Если в некотором столбце типа даты имеют значение только месяц и год (мало ли, точность до числа не нужна), есть ли смысл разделать его на MONTH и YEAR, или лучше повесить ограничение типа
(или иное условное число)?
3. В каком типе лучше хранить МФО, ЕГРПОУ, ИНН и прочие числовые ЕК: целочисленном или строковом? И почему?
4. Есть ли смысл создавать отдельные поля для фамилии, имени и отчества? Для серии и номера паспорта? Для кода города и собственно номера телефона?
P.P.S. Все ответы просьба давать под Oracle 12c и Firebird 3.0, причём желательно отдельно, если они различаются.

ymagЕсли дом частный или всего один счетчик на многоэтажный дом, то квартира в этом доме всего одна и её номер НОЛЬ.
Именно 0 как число? NULL не прокатит? Всё равно ведь сам по себе номер квартиры не м.б. ключом.
И нельзя ли обойтись без создания таких квартир-пустышек?

ymagне ключи потому, что за владельцем одного паспорта может числиться несколько квартир
По-моему, словосочетание по проектированию в общем в постскриптуме должно было дать понять, что следующие вопросы уже не являются частью ТЗ.
М-да... Хотел не плодить темы, задав все интересующие вопросы в одной, а получилось, что все вопросы привязали к одной задаче.

vmagСтроковом - строка, она и в Африке строка (нули не пропадут ни с лева ни с права, тире тоже не редкость) - искажается только при принудительном преобразовании
А если точно известно, что кроме цифр в таких полях ничего не будет? Всё равно лучше строка с regexp-based ограничением, чем integer?

AnSi_SrДопустим, надо начинать с других сущностей, например, абоненты (физ/юрлица/ТСЖ), индивидуальные приборы учета, общедомовые счетчики, показания приборов в динамике, платежи и т.д.
Взаимоотношения ресурсоснабжающей организации выстраиваются с абонентами, а не с домами/квартирами, т.е. адресная информация в данном случае атрибут сущности "Абонент". Или атрибут "Адрес установки" сущности "Общедомовой прибор учета".
Уж простите, сильно я абстрагировался. Естественно, куда же без таблиц организаций, абонентов, платежей и прочих необходимых...

P.S. Первый блин (в смысле тема) комом, сами понимаете...