Когда разделять столбцы в новую таблицу - PullRequest
1 голос
/ 17 июля 2009

У меня есть таблицы компаний, клиентов, поставщиков и т. Д., У всех из которых есть столбцы, связанные с адресной информацией.

Я пытаюсь выяснить, следует ли мне создать новую таблицу 'адреса' и отделить от нее все столбцы адресов.

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

Содержание адреса для меня не важно, я не буду проверять или использовать эти адреса в любых процессах принятия решений, они связаны исключительно с информацией. В настоящее время я смотрю на 5 таблиц, которые имеют адресную информацию

Ответы [ 7 ]

6 голосов
/ 17 июля 2009

Ответ на все вопросы о дизайне таков:

Это зависит.

Таким образом, в основном в случае с адресом это зависит от того, будет ли у вас более 1 адреса на одного клиента. Если у вас будет больше 1, поместите его в новую таблицу адресов и присвойте каждому адресу идентификатор клиента. Создавать общую таблицу адресов и сопоставлять ее с таблицами компании / клиента / поставщика - это излишне (в большинстве случаев это зависит!).

Кроме того, часто бывает чрезмерно (и опасно) отображать адреса в отношениях «многие ко многим» между вашими объектами (поскольку при этом адреса могут казаться волшебным образом изменяющимися для пользователей).

Единственное важное правило: будь проще!

4 голосов
/ 17 июля 2009

Это называется Нормализация базы данных . И да, вы хотите разделить их, если не по какой-либо другой причине, потому что, если вам это понадобится, в будущем будет намного сложнее, когда у вас есть код и запросы.

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

РЕДАКТИРОВАТЬ: Чтобы расширить это и добавить некоторые комментарии, которые я сделал к постам других, я убежден в том, что нужно начинать с простого дизайна, когда дело доходит до кода, и рефакторинга, когда становится ясно, что он становится слишком сложным. и более глубокие объектно-ориентированные принципы были бы уместны. Однако рефакторинг базы данных, которая находится в производстве, не так прост. Это все о рентабельности. С самого начала слишком просто спроектировать нормализованную базу данных, чтобы оправдать это. Последствия плохо спроектированной базы данных могут быть катастрофическими, и обычно уже слишком поздно, чтобы вы пришли к этой реализации.

1 голос
/ 17 июля 2009

Да, вы должны разделить адреса в своей таблице. Это умная вещь, которую нужно знать, чтобы спросить. Ключевым моментом здесь является то, что общий формат адресов одинаков, независимо от того, кто это; клиент, компания, поставщик ... все они имеют одинаковые поля для адресов.

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

1 голос
/ 17 июля 2009

Если вы используете эти адреса только в пределах их собственных таблиц, может быть не выгодно перемещать их в свои собственные таблицы.

По сути, это не похоже на то, что оно того стоит.

0 голосов
/ 16 сентября 2012

Я не согласен с Дейвом. Подход «многие ко многим» (Address <-> User) является одновременно безопасным и очень выгодным.

Когда клиент перемещается, адреса в таблице адресов НЕ меняются. Вместо этого новый адрес находится в таблице адресов, а клиент и т. Д. Связан с этой записью. Если нового адреса еще нет в таблице, он добавляется к нему.

Так изменяются ли сами записи адресов? Да, в таких случаях:

  • получается, что в адресе есть опечатка
  • Почтовая служба США меняет название улицы

Это те самые ситуации, когда размещение всех адресов в одной таблице без повторений окупается; любая другая договоренность потребует раздражающего и повторяющегося ввода данных.

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

0 голосов
/ 17 июля 2009

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

Однако, с точки зрения производительности и запросов, хранение их в соответствующих таблицах упрощает работу с точки зрения отчетности.

У меня есть ситуация с моей текущей компанией [логистика], когда адреса фактически логически одинаковы - все они находятся вне зависимости от того, где они находятся: место получения, место доставки, клиент и т. Д.

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

0 голосов
/ 17 июля 2009

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

Если три таблицы полностью независимы друг от друга, перенос данных в другую таблицу не принесет особой выгоды, поэтому вы могли бы также оставить ее в покое.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...