Most leading DB today's are RDBMS (relational database management system) .
The "relation modeling" concepets frist formulated and proposed in 1969 by E.F. Codd .
The idea is to describe a database as a collection of predicates over a finite set of predicate variables, describing constraints on the possible values and combinations of values. The content of the database at any given time is a finite (logical) model of the database, i.e. a set of relations, one per predicate variable, such that all predicates are satisfied. A request for information from the database (a database query) is also a predicate. (http://en.wikipedia.org/wiki/Relational_model).
However relation modeling cannot suite to any kind of application.
In some application there is no a restrict schema and the model is flexible.
In those cases the traditional "relation modeling" is a bad solution.
Skinny data models are one of the most notorious and problematic abuses of relational Database systems. Unfortunately, they’re sometimes necessary. A skinny data model basically turns each table into a generic data structure that can store sets of name and value pairs, much like a properties file in Java.
The relational model that these databases are built on, however, was designed many years ago, when the World Wide Web and Internet were unheard of. Although the strict schema-based structure these databases adhere to is required in some web applications, such as transaction systems, it is not a good fit for many modern web projects, such as blogs, wikis, and discussion forums, which by their nature are a better fit to a document-oriented database.
Another problem in RDBMS is making schema changes or adding indexes to a database with more than 10 - 20 million rows completely locks the database for hours at a time.
Different solutions are available. Some of them by using in specific db solutions and implemented based on existing RDBMS.
I want to focus on 2 solutions (there are a lot of alternatives), but first disclaimer.
Disclaimer:
When you decide to fall from the standard does it only after you consult with at least two different consultants, who are consider as leaders in these fields.
Falling from the standard has major impacts:
Impact on - employee training, scalability, performance, bugs and design solutions. When you take the "off road" you are missing all the benefit in the primary road like - big community, Google answers, books, solutions and so on. So be careful when you take the off road.
If you chose to take the "off road" make sure you isolate you solution as much as possible.
Famous computer scientist Butler W. Lampson (who envisioned the modern personal computer at Xerox way back in 1972) once said, “All problems in computer science can be solved by another level of indirection.” So try to encapsulate your "off road" solution as much as possible. There is a big chance that you will decide to go back to the main road in the future.
Use a solution above RDBS:
This kind of approach pulished by " FriendFeed " they choose to implement their own soltuon above MySql DB - http://bret.appspot.com/entry/how-friendfeed-uses-mysql
In the article they explain why they chose to implemrt thir own solution and not use in an existing one:
Lots of projects exist designed to tackle the problem storing data with flexible schemas and building new indexes on the fly (e.g., CouchDB). However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs (see this somewhat outdated article on CouchDB, for example). MySQL works. It doesn't corrupt data. Replication works. We understand its limitations already. We like MySQL for storage, just not RDBMS usage patterns.
Use an existing solution for example – CoachDB:
CouchDB is a document-oriented database management system, released under the open source Apache License. In contrast to most database systems, it stores data in a schema-free manner. This means that, unlike traditional SQL-based databases, there are no tables and columns, primary and foreign keys, joins, and relationships. Instead, CouchDB stores data in a series of documents and offers a
JavaScript-based view model for aggregating and reporting on the data.
Coachdb has many more advantage like replication, local data, versioning and many more.
It has a big community and good books.
One small comment – the local data feature is one of his "sexy features". This allows you to install light DB on the client side. Give the client the option to work offline and sync the client db with the server replication later. The same idea as a version control.
אין תגובות:
הוסף רשומת תגובה