Это хорошая концепция дизайна базы данных?

Question

EDIT1: попытался прояснить вопрос, переименовав таблицы и их отношения. РЕДАКТИРОВАТЬ 2: Пожалуйста, не смотрите, какой тип данных я держу в трех таблицах БД. Они были составлены на лету. Это НЕ мои сценарии реального мира (и нет, я не могу говорить о своих данных реального мира .. на самом деле это 1 родитель и 6 детей). Пожалуйста, просто игнорируйте, какой тип данных, и просто посмотрите на тот факт, что некоторые данные требуются. EDIT3: два FK являются отношениями 0 или 1 к 1. НЕ 0 для многих. Не 1 к 1. Я пытаюсь избежать отношения 0 или 1 к 1 к отношению 1 к 1, поэтому мне не нужно иметь ВНЕШНИЕ СОЕДИНЕНИЯ, а вместо этого ВНУТРЕННЕЕ СОЕДИНЕНИЕ.

Вопрос: мне нужно знать, хорош ли / плох / плох / предложен проект базы данных

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

• Три стола.
• table_User имеет FK для table_Address
• table_User имеет FK на table_Vehicle
• и т.д ..

и таблицы B и C (которые теперь работают как справочные таблицы) имеют ..

• Id INT IDENTITY PK
• Описание NVARCHAR (100) NULLABLE

замечаете обнуляемый? таким образом, что-то в table_User не существует в table_Address ... поле равно нулю (из-за внутреннего соединения).

Раньше я делал это LEFT OUTER JOIN, поэтому, если в table_b не было данных, я получу нулевые результаты для каждого поля.

Я приведу несколько примеров данных здесь ...

Table_User

• ID: 1, имя: Фред, AddressID: 1 (NULL)
• ID: 2, Имя: Джо, AddressID: 2 (1 улица Смита .....)
• ID: 3, Имя: Джейн, AddressID: 2 (1 улица Смита .....)

Table_Address

• ID: 1, описание = NULL
• ID: 2, Описание = 1 Смит-стрит

и т.д.

Итак, наконец, я могу поместить все это в индексированное представление. (в моем сценарии из реальной жизни около 8 таблиц).

ПРИМЕЧАНИЕ. БД - это Microsoft Sql Server 2008, но это может быть для любой БД.

Q1: этот дизайн кажется нормальным?

Q2: Так что я делаю здесь, я нормализую данные, верно? удерживая внутренние соединения вместе.

Q3: И наконец, если это нормально ... могу ли я также удостовериться, что данные в таблицах уникальны (например, адреса улиц), имея некоторые уникальные ограничения или ключи или индексы или что (i ' я не уверен в правильной терминологии).

спасибо гуру!

Answer 1

Я нахожу ваш вопрос запутанным, но, возможно, я могу немного помочь.

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

Рекомендую прочитать о нормализации БД. В Википедии есть отличная статья: http://en.wikipedia.org/wiki/Database_normalization

Что касается вашего текущего дела, я не уверен, что вы пытаетесь сделать. Наличие идентификатора для адреса кажется нормальным, если этот адрес повторяется в разных строках. Однако, необходимость в нескольких «адресных таблицах» кажется странной. Самые важные вещи, которые нужно помнить при проектировании: - Иметь правильный первичный ключ в каждой таблице, чтобы вы могли правильно объединять таблицы. - Не повторяйте данные, если у вас нет очень веских причин. Но я снова рекомендую предыдущую статью.

надеюсь, это поможет! :)

Answer 2

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

Подсказка: если у вас есть данные, которые повторяются, вам нужна отдельная таблица, на которую вы ссылаетесь в первой по внешнему ключу. Все остальное - просто запросы.

Answer 3

Я бы лично сказал «нет» этому дизайну. Причины:

• (может не применяться) попытка нормализовать поле адреса означает, что вам необходимо обработать это поле, чтобы избежать непреднамеренных дубликатов. То есть Вы должны убедиться, что пользователь вводит адрес в правильном формате (в противном случае «1 mystreet» также может быть введен как «1, mystreet» или как угодно - нужно проверить это, чтобы избежать дублирования, в противном случае нормализация ни к чему хорошему)
• даже если вы найдете причину для нормализации (то есть держите отдельную таблицу для адреса), концепция «фиктивного» адреса мне странна. Почему бы не использовать обнуляемое отношение FK, то есть сохранить нулевой адресный идентификатор в родительской пользовательской таблице, вместо того, чтобы просто вставить туда фиктивный идентификатор.

Answer 4

То есть вы в основном добавляете фиктивные записи в таблицы B и C, чтобы иметь такое же количество строк, как в A? Я бы не стал делать это на вашем месте, потому что если ваш набор данных велик, то вы увеличиваете количество строк без какой-либо реальной необходимости, а также вы рискуете несогласованность (ваш макет сильно зависит от вашей эти фиктивные записи вставлены). Кроме того, чего вы хотите достичь с помощью индексированного представления? Прирост производительности? Вы не пишете, какую СУБД вы используете, но из моего опыта работы с MSSQL это не принесет вам большой выгоды, поскольку при условии наличия правильных индексов в таблицах A, B и C сервер сможет использовать им построить хороший план запроса даже без индексированного представления.