我应该使用单独的表格为每一个类别或一个表来存储分类网站的所有属性
本文关键字:一个 分类网站 属性 存储 表格 单独 每一个 我应该 | 更新日期: 2023-09-27 18:16:44
我正在使用asp.net开发一个分类网站,我的DB是mysql。请MSSQL用户我也需要你的支持。这是与特定数据库提供程序无关的数据库模式的问题。
我只是想让你稍微澄清一下。
所以在这里,因为这是一个分类网站,你可以发布招聘广告,汽车广告,房地产广告等…
所以我有一个标题表来存储关于广告的公共细节。如标题、描述等。
CREATE TABLE `ad_header` (
`ad_header_id_pk` int(10) unsigned NOT NULL AUTO_INCREMENT,
`district_id_fk` tinyint(5) unsigned NOT NULL,
`district_name` varchar(50) DEFAULT NULL,
`city_id_fk` tinyint(5) unsigned DEFAULT NULL,
`city_name` varchar(50) DEFAULT NULL,
`category_id_fk` smallint(3) unsigned NOT NULL,
`sub_category_id_fk` smallint(3) unsigned DEFAULT NULL,
`title` varchar(100) NOT NULL,
`description` text NOT NULL,
...............
PRIMARY KEY (`ad_header_id_pk`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
因此,如果这是一个招聘广告,我有另一个表来存储只与招聘广告相关的属性,如工资,就业类型,工作时间
如果它是一辆车,我有单独的表来存储燃料类型,传动类型等…
我有10个类别。这些类别在十年内不会改变。现在我有这两种方法
1)一个头表和10个用于存储每个头表的特定表类别属性
2)一个头表和一个属性表它将保存每个分类组的所有属性。对于那些不相关的将保存NULL值
关于性能和可伸缩性,什么是最好的方法?
对于那些谁建立分类网站请给我一个指南。提前感谢
这个问题我不是很清楚,但我可以给一些建议:
首先,如果您发现自己想要在单个列/单元格中存储分隔的值,则需要后退一步,创建一个新表来保存该信息。永远不要将分隔的数据存储在单列中。
如果我对你的问题理解正确的话,Ads
有Categories
,如"Job","For Sale","Vehicle","Real Estate"等。然后Categories
应该有Attributes
,其中属性可能是每个类别唯一的东西,如车辆类别的"传动类型"或"里程",或房地产类别的"平方英尺"或"建造年"。
处理这种情况的正确方法不止一种。
如果主类别是固定的,那么合理的设计选择是为每个类别的属性设置一个单独的表,这样每个广告列表将有一个来自ad_header
的记录,以及一个来自特定Attribute
表的记录。因此,车辆列表将有ad_header
记录和vehicle_attributes
记录。
如果类别比较灵活,在这种情况下,合理的设计选择是使用一个CateogryAttributes
表,它定义每个类别使用的属性,以及一个Ad_Listing_Attributes
表,它保存每个清单的属性数据,它将包括CategoryAttributes
和Ad_header
的外键。注意,该表的模式有效地遵循实体/属性/值模式,这种模式被广泛认为实际上是一种反模式。也就是说,这在大多数情况下是要避免的。但是,如果您希望经常添加新类别,那么这可能是您可以在这里做的最好的事情。
最后一个选项是将所有类别的属性放在一个大表中,只填充需要的属性。因此,车辆列表将只有一个ad_header
记录,但记录中会有很多NULL
列。在这种情况下,我将避免这样做,因为理想的场景可能需要某些类别的某些属性(例如:NOT NULLABLE列),但保留其他选项。
这是Postgresql可能是更好的数据库选择的另一个例子。Postgresql有一种叫做表继承的东西,它是专门为解决这种情况而设计的,允许你避免EAV表模式。
完全披露:我实际上是一个Sql Server家伙在大多数情况下,但它似乎是Postgresql可能更适合你。我的经验是,MySql在90年代末和00年代初还不错,但从那以后就真的落后了。它今天仍然很受欢迎,主要是因为早期的势头以及廉价的托管可用性的一些优势,而不是任何真正的技术优点。