Это хорошая практика обмена адресной таблицей с двумя объектами?

Question

У меня есть две сущности в моей базе данных, для которых требуются адреса. Оба могут иметь один адрес для ID.

Место проведения Таблица:

create_table "venues", force: :cascade do |t| 
t.string "name" 
t.text  "description" 
t.string "email" 
t.string "phone" 
t.integer "category_id" 
t.datetime "created_at",  null: false 
t.datetime "updated_at",  null: false 
end 

Таблица Пользователь

create_table "users", force: :cascade do |t| 
t.string "first_name" 
t.string "surname" 
t.string "email" 
t.datetime "created_at",  null: false 
t.datetime "updated_at",  null: false 
end 

Адрес таблица мест имеет две колонки не нужны для пользователей. Ширины широты и долготы.

В этом случае это хороший подход, создающий таблицу адресов с внешним ключом для пользователей и другую таблицу адресов с внешним ключом для места? Какое лучшее решение для этого?

Answer 1

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

Имейте все адреса в одной таблице. Это почти без исключения лучшая практика. Создайте отдельную таблицу для хранения координат. Поскольку это отношение 1-1, PK этой таблицы также является FK по адресам, к которым они привязаны.

create table Coords(
    AddrID int not null primary key 
     references Addresses(ID), 
    Latitude CoordType not null, 
    Longitude CoordType not null 
); 

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

create view UsersWithAddr as 
    select u.f1, u.f2, ..., a.f1, a.f2,... 
    from Users u 
    join Addresses a 
     on a.ID = u.AddrID; 


create view VenuesWithAddr as 
    select v.f1, v.f2, ..., a.f1, a.f2,..., c.Latitude, c.Longitude 
    from Users u 
    join Addresses a 
     on a.ID = u.AddrID 
    join Coords c 
     on c.AddrID = a.ID; 

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

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