ModelRПричины для нескольких таблиц
Некоторые СУБД не допускают более одного поля типа BLOB в таблице.
Редко используемые поля - в отдельный файл, тейблспейс.
Очень большой поцент NULL в полях - но с эконмией на пустых значениях обычно СУБД справляются без посторонней помощи.
ИМХО Все что можно, собрать в одну таблицу.

А все такие ухищрения "Редко используемые поля - в отдельный файл, тейблспейс" реально необходимы для всероссийской переписи населения. Или для общероссийских операторов связи. Только вот думаю что разработчики этих программ не спрашивают на SQL.RU советов ;)

А так сколько клиентов у среднего предприятия 100-1000?

_spy_Ну здесь ведь еще не только вопрос нормализации и экономии дискового пространства, но и вопрос конфликтов при одновременном доступе. При редактировании таблицы с сотней полей легче нарваться на конфликт при обновлении, чем когда таблица разбита на несколько более мелких.
Представьте себе ситуацию, когда один оператор меняет ФИО контрагента, а другой его пол ;) Справочник клиентов это не та информация которая требует дополнительных затрат на потенцифльную проблему "одновременного доступа".

А вот обратная ситуация когда таблицы связаны 1:1 и при импорте данных кто-то забудет внести строчку в 4-ую таблицу, или наоборот забудет удалить из 3-ей это намного более типичная ошибка.

proposed amendment
кроме того, это еще и вопрос унификации и повторяемости решения...
какой смысл каждый раз по-новой решать одну и ту-же задачу...

Абсолютно согласен. Базовый функционал у нас для различных приложений не менялся несколько лет, не считая бантиков типа внесения "ЕГРН"

proposed amendment
у меня в таблице контактов хранятся только Native Properties - Идентификатор, Имя/фамилия/Отчество, Пол, Дата_рождения

все остальные данные разложены по разным таблицам - удостоверения/виды удостоверений, телефоны, адреса и проч... все связано либо Многие_ко_многим либо один_ко_многим...

А вот с этим позволю не согласиться, и не только из за возможных DealLock, но и из за сложности в поддержке такого решения.

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

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

softwarer EstetsВозможно со мной не согласятся многие сторонники нормализации БД, но привиду пример, у нас юридический адрес лежит в той же таблице где и остальные данные о партнере. Хотя казалось бы есть еще несколько адресов
Имхо пока что тут не с чем соглашаться или не соглашаться - вопрос в том, чем оправдана данная конкретная денормализация. Скажем, понятно, что для человека достаточно естественно хранить в основной таблице его текущее ФИО, хотя рядом лежит история изменений.
Вопрос поднятый cln75 был "Как лучше организовать" я поделился особенностями реализации в которой я участвовал. Надеюсь эта информация кому-нибудь поможет.

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

Кстати несмотря на такой простой, на первый вгляд вопрос, тут есть много интересных нюансов. Например как хранить адреса. В одной таблице, в привязанной 1:N, в строке, выбирать страны-города из справочников или нет, поддерживать структуру КЛАДР или нет...

Кто может поделиться соображениями?

softwarer
Хм. Странное утверждение :)
Не помню флейм, можно сказать так "конечное количество соответствующее ТЗ" ;)

softwarer EstetsНапример как хранить адреса. В одной таблице, в привязанной 1:N, в строке, выбирать страны-города из справочников или нет, поддерживать структуру КЛАДР или нет...
И для какой задачи? Имхо бессмысленно говорить об этом "вообще". И кстати есть еще более интересные ньюансы: например, коллеги, работающие сейчас на проекте по Data Hub в одном официальном учреждении, рассказывают, что в "тех базах" поле адреса помимо уймы более или менее ожидаемых прелестей еще и использовалось операторами для хранения комментариев.
Ну в этом тоже есть некоторая ошибка программистов, значит не было предусмотрено поле комментарий для партнера.
softwarer
Скажем, у меня была задача к организации хранить список из нескольких ее сотрудников с должностями-телефонами. Вводить этих сотрудников как физлиц не хотелось; в итоге была сделана одна табличка типа имя-должность-телефон.
Я не собираюсь строить супер-универсальную систему для учета партнеров, но полезно иметь базовую структуру, для ее хранения в которой учтены хотя бы некоторые грабли из других проектов.

Например у нас адрес хранится строкой, за исключением индекса и страны (справочник), соответственно для печати использовалась структура:
Но буквально недавно один из клиентов вернул нам счет-фактуру на основании того что в поле "адрес" должен попадать такой адрес как он указан в учередительных документах. А у него в документах слов "Российская федерация" нет ;-(.

И вот пришлось написать заглушку:
если клиент = <...> то при печати из адреса вырезать слово "Российская федерация".