与两个实体共享地址表是一种好习惯吗？答案

【问题标题】：Is it a good practice sharing Address Table with Two Entities?与两个实体共享地址表是一种好习惯吗？
【发布时间】：2016-09-10 15:47:22
【问题描述】：

我的数据库中有两个实体都需要地址。每个 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

场所的地址表有两列，用户不需要。纬度和经度列。

在这种情况下，创建一个带有用户外键的地址表和其他带有场地外键的地址表是一个好方法吗？什么是最好的解决方案？

【问题讨论】：

标签： mysql ruby-on-rails database database-design polymorphic-associations

【解决方案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
);

我要添加的是对应用程序开发人员的一些便利。在 Users 和 Venues 表的前面使用视图来公开表数据并附加地址数据。

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 的不需要的字段，并且应用程序将以他们希望看到的形式查看地址数据，具体取决于它们是否正在查看用户或场所。

【讨论】：