【问题标题】:opinions and advice on database structure关于数据库结构的意见和建议
【发布时间】:2011-08-25 14:32:33
【问题描述】:

我正在构建这个用于分类数据的工具。基本上我会定期在一个平面文件中接收数据行,如下所示:

a:b:c:d:e
a:b:c:d:e
a:b:c:d:e
a:b:c:d:e

我有一个类别列表,可以将这些行分解为,例如:

Original   Cat1  Cat2  Cat3  Cat4  Cat5
---------------------------------------
a:b:c:d:e  a     b     c     d     e

截至目前,类别名称以及用于分解数据的类别数量是已知的。但这可能会随着时间的推移而改变(例如,添加/删除的类别......改变的类别总数)。

好的,所以我并不是真的在寻求有关如何解析行或将数据放入数据库或其他任何东西的帮助...我知道如何做所有这些,并且已经编写了大部分核心脚本来处理解析值行并分成不同数量的类别。

我主要是在寻找有关如何构建我的数据库来存储这些东西的建议。所以我一直在考虑,这就是我想出的:

Table: Generated
generated_id        int           - unique id for each row generated
generated_timestamp datetime      - timestamp of when row was generated
last_updated        datetime      - timestamp of when row last updated
generated_method    varchar(6)    - method in which row was generated (manual or auto)
original_string     varchar (255) - the original string

Table: Categories
category_id         int           - unique id for category
category_name       varchar(20)   - name of category

Table: Category_Values
category_map_id     int           - unique id for each value (not sure if I actually need this)
category_id         int           - id value to link to table Categories
generated_id        int           - id value to link to table Generated
category_value      varchar (255) - value for the category

基本上这个想法是当我解析一行时,我将在表 Generated 中插入一个新条目,以及在表 Category_Values 中插入 X 个条目,其中 X 是当前有许多类别。并且类别名称存储在另一个表中Categories

我的脚本将立即执行处理原始值行并将生成的类别值输出到要发送到某处的新文件。但是后来我有了这个数据库来存储生成的数据,这样我就可以制作另一个脚本,在那里我可以搜索并列出以前生成的值,或者用新值或其他内容更新以前生成的条目。

这看起来像一个好的数据库结构吗?有什么明显的我遗漏或可能自欺欺人吗?比如这个结构……嗯……我不是sql专家,但我想我应该可以做到

select * from Generated where original_string = '$string'
// id is put into $id

然后

select * from Category_Values where generated_id = '$id'

...然后我将使用我的数据来处理搜索结果或表单以更改数据...嗯,我很确定我什至可以将它与连接或其他东西组合成一个查询,但我'我对 sql 不是很好,所以我不知道如何真正做到这一点..但重点是,我知道我 可以 从这个 db 结构中做我需要的事情.. 但我是否让这更难比它需要的?犯了一些明显的菜鸟错误?

【问题讨论】:

  • 欢迎来到stackoverflow,非常好的问题,良好的布局和大量的背景。
  • FWIW: select * from Category_Values where generated_id in (select generated_id from Generated where original_string='$string')
  • 谢谢耶利米,会写下来的:)

标签: mysql sql database-design data-modeling


【解决方案1】:

我的建议:

Table: Generated
id                  unsigned int autoincrement primary key
generated_timestamp timestamp
last_updated        timestamp default '0000-00-00' ON UPDATE CURRENT_TIMESTAMP
generated_method    ENUM('manual','auto')
original_string     varchar (255)

Table: Categories
id                  unsigned int autoincrement primary key
category_name       varchar(20)   

Table: Category_Values
id                  unsigned int autoincrement primary key
category_id         int           
generated_id        int           
category_value      varchar (255) - value for the category
  FOREIGN KEY `fk_cat`(category_id) REFERENCES category.id
  FOREIGN KEY `fk_gen`(generated_id) REFERENCES generated.id

链接
时间戳:http://dev.mysql.com/doc/refman/5.1/en/timestamp.html
创建表语法:http://dev.mysql.com/doc/refman/5.1/en/create-table.html
枚举:http://dev.mysql.com/doc/refman/5.1/en/enum.html

【讨论】:

  • 谢谢!是的,实际上我会让列类型相似,比如 ID 和东西的自动增量。我不完全确定其中一些东西的用途(比如外键/引用的东西),但我可以很容易地进行研究以找出答案。
【解决方案2】:

我认为这个解决方案非常适合您想要做的事情。类别列表现在很灵活,因此您可以添加新类别或淘汰旧类别(我建议您在同意删除类别之前仔细考虑一下 - 您会孤立记录还是删除它们等等)

基本上,我是说你的目标是正确的。结构很简单,但它对你很有效。干得好(并且在问题中提供了正确数量的信息)。

【讨论】:

  • 谢谢 :) .. 我对类别名称或类别名称没有真正的影响力。多年来,客户基本上一直在用 excel 手动创建输出文件,并聘请我来自动化该过程。因此,根据他们的历史,我知道类别不会经常变化,但它们有时会发生变化,因为业务需求会发生变化。总的来说,它基本上只是分解原始值并创建分类,所以基本上只是以不同的方式查看相同的数据,并且(重新)分类是追溯性的,所以当它确实改变了。
猜你喜欢
  • 1970-01-01
  • 2011-06-22
  • 1970-01-01
  • 1970-01-01
  • 2013-05-20
  • 2017-09-01
  • 2014-09-26
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多