Проблема в том, что вопрос немного изолирован. Но поскольку вы обеспокоены тем, имеет ли проблема теоретическое (и, возможно, соответствие стандартам), ответ должен , а не быть настолько изолированным.
Если да, рекомендуется ли это теоретически или нет?
Нет. У него нет никаких академических или теоретических основ. Он нарушает основные правила проектирования реляционной базы данных, и поэтому (а) не будет создавать реляционную базу данных и (б) все, что будет создано, не будет иметь возможности реляционной базы, которую пользователи (без необходимости проходить через приложение) будут ожидать через множество простых инструментов для создания отчетов по реляционной базе данных.
На самом деле это, к сожалению, очень распространенный, быстрый и грязный метод создания электронных таблиц (которые разработчик приложения определил для своего приложения) вписывается в «базу данных» контейнер такие как MS SQL. Без выполнения каких-либо подлинных работ по проектированию или моделированию базы данных, которые требуются для содержимого контейнера, чтобы квалифицироваться как реляционная база данных. Хорошо подходит для создания прототипа или подтверждения концепции, но не готов к любой форме разработки (кодирование SQL).
Можно ли добавить поле «ID» в качестве первичного ключа ко всем таблицам моей базы данных, а также использовать его для установления связей между таблицами?
Держись. Они не могут быть "таблицами базы данных" по определению. Таблицы базы данных получены в результате формального процесса моделирования, и в результате будут иметь сильные идентификаторы. И отношения уже определены. В этом случае вопрос не будет задан. Следовательно, так как его спрашивают, то вещей , о которых вы спрашиваете, далеко не близки к «таблицам базы данных». Это всего лишь блокнот разработчиков одного приложения для одного приложения.
Добавление ограничения FK к одной электронной таблице, чтобы «связать» его с другой электронной таблицей, и добавление «ID» PK не создает «реляционную» «базу данных». Нет, он просто использует возможность SQL связывать иные несвязанные электронные таблицы в контейнере. Они остаются несвязанными электронными таблицами, «связанными» с помощью добавленного «ID» столбца.
Результатом является существенное дублирование данных; обновить аномалии; много других показателей; большие «реляционные» наборы данных; низкая производительность; массовое чрезмерное использование временных таблиц; сложный SQL, которого можно избежать с помощью подлинного проектирования баз данных.
Будет ли этот дизайн рассматриваться как проект 3NF (третья нормальная форма)?
Нормализация является частью (не всем) процесса проектирования базы данных. 3NF достигается через этот процесс. 3NF или любой другой NF, не является этикеткой, которая может быть размещена на множестве электронных таблиц или частично разработанного содержимого контейнера, не проходя процесс и, таким образом, зарабатывая значок. Никто не «рассматривает» кучу электронных таблиц или частично разработанное содержимое 3NF; оценивается, были ли соблюдены правила нормализации, и если эти правила не нарушаются, то это справедливо обозначается как 3NF. Поскольку процесс нормализации не соблюдался, нет оснований предполагать, что он может относиться к любой нормальной форме.
Аналогично, сверх Нормализации, если правила Реляционной базы данных соблюдались в течение процесса и не нарушались, достигается соответствие стандартам Реляционной базы данных. Поскольку методология реляционной базы данных не соблюдалась, нет оснований предполагать, что она может относиться к какому-либо стандарту реляционной базы данных или что от него можно ожидать любой реляционной возможности.
Общее представление о проблеме
«Идентификаторы» - это суррогатные ключи. Суррогатные ключи - это всегда (вы правы) дополнительный ключ и индекс , дополнительный к существующему PK, который собирается узурпировать. Конечно, это требует значительных затрат производительности при каждом доступе.
У некоторых спрашивающих есть идея, что суррогатные ключи могут использоваться вместо PK.Что, конечно, неверно, и вы понимаете, что, с такой благодарностью, что здесь нет необходимости обращаться к этому.
Понятие «все суррогатные ключи» или «нет суррогатных ключей» - это вид черного или- белая бессмысленная ерунда, которая является нормальной для детей, но неприемлемой для взрослых, особенно для тех, кто занимается ИТ-работой, что требует точности и понимания.Для маленького ребенка вполне нормально думать "если папа не позволяет мне делать то, что я хочу, он меня не любит", и, следовательно, ", если он меня не любит, он ненавидит меня ".Большинство из нас понимают, что жизнь немного сложнее, чем к возрасту начальной школы.Разработчики, которые «любят» видеть «идентификаторы» в каждой таблице и «не любят» их отсутствие в некоторых таблицах, по определению не способны рассматривать базу данных в целом и потребности других разработчиков и пользователей;они думают только об упрощенном коде «одна таблица за раз».
Это также , а не о оттенках серого или размытых определениях.Нет, определения не изменились за 30 лет (они были расширены и уточнены, но они не изменились).Оттенки серого позволяют разработчикам избегать соответствия стандартам.Так что это тоже не рекомендуется.
Что такое подлинная реляционная база данных?
Правда в том, что если база данных была честно смоделирована и спроектирована, с помощью квалифицированных данныхМодельер, используя методологии, которые доступны в течение 30 лет, в итоге получит подлинно реляционную базу данных.И если бы они не следили за процессом, это не было бы ни реляционной, ни базой данных.Идентификаторы и отношения уже будут определены, и значение, контекст этого будет перенесен в различные таблицы.Данные будут нормализованы до 3NF или BCNF или 5NF, и аномалий обновления не будет.На последнем шаге , как части формального процесса, и , а не вне его, при переводе логического в физическое модельер может улучшить производительность некоторые Идентификаторы, добавляя суррогатные ключи и избегая переноса больших (широких) ключей в связанные дочерние таблицы (1).Это еще раз доказывает, с другого подхода, почему понятие нулевых суррогатов, или всех суррогатов, является детским и полностью исключено из подлинного процесса.
Настоящая реляционная база данных будет иметь полную реляционную возможность, честное достижение 3NF, использовать естественные реляционные ключи, при этом некоторые из них будут вдумчиво переключены на суррогаты.
Легко доказано
Конечно, все, что я изложил, может быть легко доказано: просто отправьте DDL от 5 до 10 ваших электронных таблиц, мне нужна глубина не менее четырех (great.grand.parent⇢grand.parent⇢parent⇢child).
Вас может заинтересовать, я недавно опубликовал информацию о вашем вопросе в связанных вопросах , которые я здесь не повторяю.
Примечание
Это требуется только потому, что текущие предложения SQL не поддерживают полную реляционную модель и устраняют известные им препятствия в производительности, которые у них возникают.,И не будет необходимости, если и когда поставщики предоставляют реляционные базы данных, в которых широкие реляционные ключи работают так же хорошо, как и узкие.
Я согласен с заявлениями Эрвина о ключах и идентификаторах, и поэтому я не повторял их в своем ответе.