我有一个系统(为了一个简单的例子),包括客户,供应商,产品,销售等。目前共有24个表。
我想为这些表中的每条记录添加多个备注的功能。例如,每个客户记录可以有0到多个注释,每个供应商记录可以有0到多个注释等。
我的想法是,我希望有一个“Notes”表,由Noteid和日期/时间戳索引。实际的音符数据是varchar(255)。
我正在寻找一种创造性的方法来将源表双向绑定到Notes表。拥有24个外键类型交叉引用表或24个Notes表的想法并没有真正抓住我。
使用Apache服务器在PHP中进行编程。数据库是mysql / InnoDB。
开放创意。
由于
拉尔夫
答案 0 :(得分:1)
我会建议像这样的表
note_id : int autoincrement primary
type_id : int, foreign key from f Customers, Vendors, Products etc
type : varchar, code indicating the type, like Vendors, VENDORS or just V
note : varchar, the actual node
CREATE TABLE IF NOT EXISTS `notes` (
`note_id` int(11) NOT NULL AUTO_INCREMENT,
`type_id` int(11) NOT NULL,
`type` varchar(20) CHARACTER SET utf8 NOT NULL,
`note` varchar(255) CHARACTER SET utf8 NOT NULL,
PRIMARY KEY (`note_id`)
)
通过这样的设置,您可以为每种类型提供多个注释,例如供应商,还可以保存多种类型的注释。
数据样本
note_id type_id type note
--------------------------------------------------------------------
1 45 Vendors a note
2 45 Vendors another note
3 3 Customers a note for customer #3
4 67 Products a note for product #67
SQL示例
select note from notes where type="Vendors" and type_id=45
为减少表格大小,我更喜欢类型的别名,例如V
,P
,C
等。
答案 1 :(得分:0)
不要做“通用”表格,例如
id,source_table,source_record_id,note_text
在实践中可能听起来不错,但是如果不编写动态SQL,就无法将此表连接到其他人。
简单地为每个表添加一个专用的备注字段要好得多。这消除了对动态sql的任何需求,如果使用varchar / text字段,额外的空间使用将是最小的,因为它们不会存储在表中。
答案 2 :(得分:0)
在我使用这样的格式之前,我已经完成了这样的结构:
id (int)
target_type (enum/varchar)
target_id (int)
note (text)
每个数据元素只需查询它自己的类型,因此对于您的客户对象,您将查询附加到它的注释,如下所示
SELECT * FROM notes where target_type='customer' AND target_id=$this->id
您还可以将target_type链接到实际的类,以便使用get_class($ this)写入数据库以填充目标类型,在这种情况下,Note类中的单个函数可以接受任何其他对象类型你有。
答案 3 :(得分:0)
在我看来,没有一个干净的解决方案。
每个(相关)表的每个(相关)行在表中都有一个主条目(让我们称之为entities_tbl
。每个派生表的id不是自动增量,而是引用主表的外键表
现在,您可以轻松地将notes表与主实体ID链接。
PRO:这是一个面向对象的想法。就像一个基础“对象”类,它是每个其他类的父亲。此外,每个实体在数据库中都有唯一的ID。
CON:这是一团糟。每个实体ID分散在(至少)两个表中。您每次都需要JOIN,并且主实体表将是巨大的(它将包含与每个其他子表的总和相同的行数,组合)
在notes表中,主键包含一个自动增量,即entity_id和item_table_name。这样,您可以轻松地从任何表中提取任何实体的注释。
PRO:易于编写,易于填充 CON:它需要元值来提取实际值。没有外键可以授予引用完整性,凌乱和草率的连接,表名作为条件。
(叹了口气,我从未考虑过给出这个建议) 在每个需要注释的表中添加一列。将注释存储为json编码的字符串。 (这意味着对数据库进行非规范化,因为你将引入非原子值)
PRO:编写简单快捷,即使对于未来的数据库用户也使用某种形式的标准,这些笔记是集中的,可以从每个实体轻松访问 CON:数据库没有规范化,差异搜索和笔记之间的比较