您将如何设计数据库以允许用户定义的架构

Question

If you have to create an application like - let's say a blog application, creating the database schema is relatively simple. You have to create some tables, tblPosts, tblAttachments, tblCommets, tblBlaBla… and that's it (ok, i know, that's a bit simplified but you understand what i mean).

What if you have an application where you want to allow users to define parts of the schema at runtime . Let's say you want to build an application where users can log any kind of data. One user wants to log his working hours (startTime, endTime, project Id, description), the next wants to collect cooking recipes, others maybe stock quotes, the weekly weight of their babies, monthly expenses they spent for food, the results of their favorite football teams or whatever stuff you can think about.

How would you design a database to hold all that very very different kind of data? Would you create a generic schema that can hold all kind of data, would you create new tables reflecting the user data schema or do you have another great idea to do that?

If it's important: I have to use SQL Server / Entity Framework

Answer 1

Let's try again.

If you want them to be able to create their own schema, then why not build the schema using, oh, I dunno, the CREATE TABLE statment. You have a full boat, full functional, powerful database that can do amazing things like define schemas and store data. Why not use it?

If you were just going to do some ad-hoc properties, then sure.

But if it's "carte blanche, they can do whatever they want", then let them.

Do they have to know SQL? Umm, no. That's your UIs task. Your job as a tool and application designer is to hide the implementation from the user. So present lists of fields, lines and arrows if you want relationships, etc. Whatever.

Folks have been making "end user", "simple" database tools for years.

"What if they want to add a column?" Then add a column, databases do that, most good ones at least. If not, create the new table, copy the old data, drop the old one.

"What if they want to delete a column?" See above. If yours can't remove columns, then remove it from the logical view of the user so it looks like it's deleted.

"What if they have eleventy zillion rows of data?" Then they have a eleventy zillion rows of data and operations take eleventy zillion times longer than if they had 1 row of data. If they have eleventy zillion rows of data, they probably shouldn't be using your system for this anyway.

The fascination of "Implementing databases on databases" eludes me.

"I have Oracle here, how can I offer less features and make is slower for the user??"

Gee, I wonder.

Answer 2

There's no way you can predict how complex their data requirements will be. Entity-Attribute-Value is one typical solution many programmers use, but it might be be sufficient, for instance if the user's data would conventionally be modeled with multiple tables.

I'd serialize the user's custom data as XML or YAML or JSON or similar semi-structured format, and save it in a text BLOB.

You can even create inverted indexes so you can look up specific values among the attributes in your BLOB. See http://bret.appspot.com/entry/how-friendfeed-uses-mysql (the technique works in any RDBMS, not just MySQL).

Also consider using a document store such as Solr or MongoDB . These technologies do not need to conform to relational database conventions. You can add new attributes to any document at runtime, without needing to redefine the schema. But it's a tradeoff -- having no schema means your app can't depend on documents/rows being similar throughout the collection.

---

I'm a critic of the Entity-Attribute-Value anti-pattern.

I've written about EAV problems in my book, SQL Antipatterns: Avoiding the Pitfalls of Database Programming .

Here's an SO answer where I list some problems with Entity-Attribute-Value: " Product table, many kinds of products, each product has many parameters ."

Here's a blog I posted the other day with some more discussion of EAV problems: " EAV FAIL ."

And be sure to read this blog " Bad CaRMa " about how attempting to make a fully flexible database nearly destroyed a company.

Answer 3

I would go for a Hybrid Entity-Attribute-Value model, so like Antony's reply, you have EAV tables, but you also have default columns (and class properties) which will always exist.

Here's a great article on what you're in for :)

As an additional comment, I knocked up a prototype for this approach using Linq2Sql in a few days, and it was a workable solution. Given that you've mentioned Entity Framework, I'd take a look at version 4 and their POCO support , since this would be a good way to inject a hybrid EAV model without polluting your EF schema.

Answer 4

On the surface, a schema-less or document-oriented database such as CouchDB or SimpleDB for the custom user data sounds ideal. But I guess that doesn't help much if you can't use anything but SQL and EF.

Answer 5

I'm not familiar with the Entity Framework, but I would lean towards the Entity-Attribute-Value ( http://en.wikipedia.org/wiki/Entity-Attribute-Value_model ) database model.

So, rather than creating tables and columns on the fly, your app would create attributes (or collections of attributes) and then your end users would complete the values.

But, as I said, I don't know what the Entity Framework is supposed to do for you, and it may not let you take this approach.

Answer 6

多年前由一个可能比你或我更好的程序员团队完成的sqlservers“CREATE TABLE”语句重新实现，为什么不以有限的方式向用户公开SQLSERVER - 让他们创建他们以有限的方式拥有自己的架构，并利用SQLServer的强大功能来正确地完成它。

Answer 7

Not as a critical comment, but it may help save some of your time to point out that this is one of those Don Quixote Holy Grail type issues. There's an eternal quest for probably over 50 years to make a user-friendly database design interface.

The only quasi-successful ones that have gained any significant traction that I can think of are 1. Excel (and its predecessors), 2. Filemaker (the original, not its current flavor), and 3. (possibly, but doubtfully) Access. Note that the first two are limited to basically one table.

I'd be surprised if our collective conventional wisdom is going to help you break the barrier. But it would be wonderful.

Answer 8

I would just give them a copy of SQL Server Management Studio, and say, "go nuts!" Why reinvent a wheel within a wheel?

Answer 9

看看这篇文章，你可以做到，但这是一项艰苦的工作:)如果性能不是一个问题，xml解决方案也可以工作，虽然这也是很多工作。