【问题标题】:one big table or normalized two tables insert select performance一张大表或规范化两张表插入选择性能
【发布时间】:2014-01-06 09:57:26
【问题描述】:

我有以下创建语句:

    CREATE TABLE venues
(
  id integer NOT NULL,
  fs_id varchar,
  name varchar,
  phone varchar,
  address varchar,
  latitude double precision,
  longitude double precision,
  city varchar,
  state varchar,
  country varchar,
  category_fs_id varchar,
  category_name varchar,
  CONSTRAINT pk_venue_id PRIMARY KEY (id)
);

我可以通过一个查询得到我想要的,但是列太多了,所以我可以再创建一个表,例如:

CREATE TABLE venues
(
  id integer NOT NULL,
  fs_id varchar,
  name varchar,
  category_fs_id varchar,
  category_name varchar,
  venue_info_id integer,
  CONSTRAINT pk_venue_id PRIMARY KEY (id)
  CONSTRAINT fk_venue_info_id FOREIGN KEY (venue_info_id)
  REFERENCES venue_info (id) MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE NO ACTION
);


CREATE TABLE venue_info
(
  phone varchar,
  address varchar,
  latitude double precision,
  longitude double precision,
  city varchar,
  state varchar,
  country varchar,
);

但在此之后,我应该为选择查询中的每个插入和连接表编写两个查询 它会降低性能还是即使在这种情况下我也可以用一个查询来做到这一点?

【问题讨论】:

  • “列太多”是为了什么?

标签: sql postgresql normalization


【解决方案1】:

如果所有这些信息都是特定于场地的,那么您应该将其保存在一张桌子上,而不是使用一张单独的桌子来存放额外的信息。一个表中最多可以有大约 1600 列,具体取决于类型。 (尽管您可能不应该这样做!)尽量让您的表格代表您正在处理的实体 - venue_info 并不是真正的特定事物。

虽然我可以看到一个论点,即如果您有许多实体的地址都需要相同的详细信息,那么在您的系统中拥有一个单独的 address 表。

【讨论】:

    【解决方案2】:

    我的意见。 无需细分,因为该表包含所有地址详细信息,仅此而已。我们为什么要分解表结构,goes here。 希望这个链接能帮到你。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-03-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多