Дизайн базы данных: определение отношения между объектами в базе данных

Question

Я хочу создать базу данных для своего приложения, и у меня возник вопрос о том, как определить связь между объектами.

У меня есть два связанных объекта, ID которых является составным. Например:

• адрес лицо, идентифицируются свойствами [улица, номер дома, город, страна], а также номер телефона (хх-YYYYYY)
• сущность, которая определяется свойствами [номер региона, номер].

Отношения является «Для каждого адреса есть несколько телефонных номера, у меня есть два возможных способ определения таблицы:.

1. таблица, соединявшей всех поля ID
   • Адрес → [номер улицы, номер дома, город, страна, ..., регион номер, номер]
   • Номер телефона → [номер региона, номер, ...]
2. Таблицы с полем идентификатора (GUID), которые связаны этим полем.
   • Адрес → [ID, улица, номер дома, город, страна, ...,]
   • PhoneNumber → [ID, номер региона, число, ..., AddressID]

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

Мой вопрос - какой лучший способ? (по производительности, обслуживанию, дизайну и т. д.)

Answer 1

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

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

Единственный правильный способ спроектировать это (общее) 1: п отношения:

 
Address    PhoneNumber 
-------    ----------- 
*ID   <---+  *ID 
StreetNumber +--- AddressID 
HouseNumber   RegionNumber 
City     TheNumber 
Country    ... 
... 

* обозначает первичные ключи, как правило, автоинкрементный номер с уникальным индексом на нем.

Стрелка обозначает отношение внешнего ключа.

Answer 2

Есть ли у вас G UID второй вариант проще кодировать и конструировать. Когда вы выбираете данные путем объединения двух таблиц, вам нужно будет только индексировать столбцы идентификаторов. Другим способом вам нужны составные индексы для этого объединения.

Наличие уникальных первичных ключей в таблицах в корпоративной корпоративной системе является ценной практикой в ​​моем опыте. (как с точки зрения dba, так и с точки зрения разработчика)

Проектирование базы данных для производительности - сложная проблема, связанная со многими критериями. Вместо того, чтобы идти за теорией, если у вас есть Oracle, играйте с двумя своими подходами на практике и используйте инструменты объяснения плана. Я имею в виду создавать таблицы с указанными вами подходами, играть с индексами и использовать план объяснений. Если я не ошибаюсь, Oracle даже дает вам представление о производительности запроса при проектировании (т. Е. Позволяет оценить количество строк в таблицах). Я не уверен, что версия Express Edition поддерживает эту поддержку.