我正在开发模块化CMS,我正在考虑内容架构。我需要一个灵活的系统,可以轻松创建不同的内容类型。每种内容类型都有一个处理它的模块(或其他模块中的方法)。该模块处理创建,操作和帮助显示内容(视图负责查看内容和模块,为他们提供信息)。
每种内容类型都有自己的表格,并且不知道其他内容类型。
Contents和Content_types是负责存储内容信息的表。
Contents
---------------------------------------------------------------------------------------
id slug content_type_id in_table_id language_id uid parent_id
1 about-us 1 1 1 83j8je29 0
2 o-nama 1 2 2 83j8je29 0
3 first-page 1 3 1 12j83j28 0
4 prva-strana 1 4 2 12j83j28 0
5 news 2 1 1 mSk2919k 0
6 vijesti 2 2 2 mSk2919k 0
7 breaking-title 3 1 1 B8392mkA 5
8 vazna-vijest 3 2 2 B8392mkA 6
Content_types
------------------
id content_type
1 page
2 category
3 article
内容表包含内容的slug,内容类型,该类型内容表格中内容的ID,语言ID,uid - 这是内容所特有的,因此我们可以轻松配对多语言内容和父母ID。
这是语言表...
Languages
---------------------------
id friendly_name sid
1 english eng
2 hrvatski cro
这是内容类型表的一个示例。
Pages
---------------------------------------------------------------
id title content author_id
1 About Us This is a page about us blah blah 5
2 O nama Ovo je stranica o nama 5
3 First Page Content 2
4 Prva strana Sadržaj 3
那么,所有这些功能如何?
假设我们去: http://www.website.org/en/about-us
另一个例子: http://www.website.org/en/news/breaking-title
如果我们转到http://www.website.org/en/news/,它会确定它是一个类别并调用负责处理类别的模块并执行我们需要的操作(在这种情况下显示所有子项内容)
我想我想出了一个非常灵活的系统,但由于我不是真正有经验的程序员(我17岁),我不太确定,所以我问你对这个概念有什么看法?
答案 0 :(得分:1)
我最近成为了将这些类型的数据存储为metadata的粉丝。明显的好处是,您可以为所有内容类型创建一个表,并且(具有5NF规范化数据库结构)最多两个附加表用于存储元数据引用和元数据实际值。这允许高级别的数据抽象和持久性的一般模型。所有这些炒作的话都转化为更快的发展。
举个例子,Elgg,一个流行的基于php的社交网络框架,在这种存储方面做得很好。 Flow3,一个概念但非常简洁的通用php开发框架,也使用元数据来保持持久性。
元数据方法的最大好处是您可以一劳永逸地忘记代码中的SQL语句。鉴于您拥有正确的持久性抽象,您可以创建持久性对象,如:
$car = new StdClass();
$car->type = 'car';
$car->fuel_required = 'petrol';
$car->engine_cc = 2400;
$car->max_passengers = 5;
$car-save();
您的持久性框架将通过迭代对象属性并将它们保存在元数据表中来处理save()函数本身。如果您需要所有这些的实例,我会再次建议安装并尝试Elgg。您将看到几乎任何类型的新内容都将插入到相同的3-4个表中。
关于使用元数据方法存在一些争议,主要是基于性能的。不可否认的是,使用这种方法,您的元表将很快填满。但是,假设您的索引已就位,即使元表中有数千万条记录,您的查询也会给出合理的响应时间。最重要的是,如果您不愿意随业务增长而扩展基础架构,可以转向“Amazon s3”或其他分布式数据存储解决方案来满足您的可扩展性需求。