很多时候,当我们规范化时,我们发现了这种情况
car(id, tag, year, make_id, model_id)
make(id, name)
model(id, name, make_id)
我正试图用类别设计来解决这个问题
car(id, tag, year, make_category_id, model_category_id)
category (id, name, description, parent_category_id) //this works like a tree
有了这个我可以在同一个数据库中解决其他问题,如:
contact(id, nickname, phone_id, email_id, address_id, person_id, company_id)
email(id, email_value, category_id) //category represent the Type(Personal, Work)
phone(id, phone_value, category_id) //category represent the Type(Cell, Home, Work,..)
address(id, address_value, category_id)//category represent the type(Billing, Physical)
因此,将所有类别放在同一个表中可以让我灵活地在树中无限期地创建类别,但我的问题是:这种方法的效率如何? 感谢
这不适用于Access dbm,但我在访问中运行SQL的快速测试以填写表单上的组合框。
在电子邮件联系表单中,我填写了电子邮件类型组合框:
SELECT c.name AS Category, category.name AS Subcategory, category.id
FROM category AS c INNER JOIN category ON c.id=category.parentcategory
WHERE c.[name]='Email';//CB populated with subcategories from Email parent category
在汽车的表格中,我填充了以下组合框:
SELECT c.name AS Category, category.name AS Subcategory, category.id
FROM category AS c INNER JOIN category ON c.id=category.parentcategory
WHERE c.[name]='Vehicle';//CB populated with subcategories from Vehicle parent category
填充了相同车型的和组合框模型:
SELECT c.name, c.id
FROM category AS c
WHERE (((c.parentcategory)=[Forms]![Car]![Combo38]));//CB populated with subcategories from Make selected parent category
答案 0 :(得分:0)
你已经找到了OTLT的一个变种,即“One True Lookup Table”数据库设计反模式。网上有很多很多文章详细讨论了为什么这可能是一件坏事。谷歌“One True Lookup Table”,甚至只是OTLT,阅读了一对,并自行确定这是否适合你现在正在做的事情。
作为一个良好的开端,这里有一篇关于Phil Factor在SimpleTalk网站上的主题文章:https://www.simple-talk.com/blogs/2008/05/29/when-the-fever-is-over-and-ones-work-is-done/