non-relational-database

I'm trying to learn about OLAP and data warehousing, and I'm confused about the difference between relational and dimensional modeling. Is dimensional modeling basically relational modeling, but allowing for redundant/un-normalized data? For example, let's say I have historical sales data on (product, city, # sales). I understand that the following would be a relational point-of-view: Product | City | # Sales Apples, San Francisco, 400 Apples, Boston, 700 Apples, Seattle, 600 Oranges, San Francisco, 550 Oranges, Boston, 500 Oranges, Seattle, 600 While the following is a more dimensional point

I know there are three different, popular types of non-sql databases. Key/Value: Redis, Tokyo Cabinet, Memcached ColumnFamily: Cassandra, HBase Document: MongoDB, CouchDB I have read long blogs about it without understanding so much. I know relational databases and get the hang around document-based databases like MongoDB/CouchDB. Could someone tell me what the major differences are between these and the 2 former on the list? Niels van der Rest The main differences are the data model and the querying capabilities. Key-value stores The first type is very simple and probably doesn't need any

We have different products that rely on relational databases for various reasons, basically the transactional nature of the operations (atomicity, consistency, etc.). This is not going to change any time soon. Given this scenario, are there any possible justifications to export the data to a NoSQL solution? Maybe Datawarehousing, Analytics, etc. Any comments are welcome. "Data" is just a vague generality without a data structure. "Relational" means the data structure is relations/tables with generic queries. ( Not automatically interleaved execution of semantically atomic concurrent

Assuming the following "schema/relationship" design what is the recommended practice for handling deletion with cascade delete like operation? Relational Schema: +---------+ +--------+ | Student |-*--------1-[Enrollment]-1--------*-| Course | +---------+ +--------+ MongoDB: +---------+ +--------+ | Student |-*----------------*-| Course | +---------+ +--------+ Given this classic design of enrollment of students to courses, having a collection of courses in students and vice versa seems to be an appropriate data model when using MongoDB (that is nothing for the relationship/enrollment table).

I am creating a system which polls devices for data on varying metrics such as CPU utilisation, disk utilisation, temperature etc. at (probably) 5 minute intervals using SNMP. The ultimate goal is to provide visualisations to a user of the system in the form of time-series graphs. I have looked at using RRDTool in the past, but rejected it as storing the captured data indefinitely is important to my project, and I want higher level and more flexible access to the captured data. So my question is really: What is better, a relational database (such as MySQL or PostgreSQL) or a non-relational or

Why should I use document based database like CouchDB instead of using relational database. Are there any typical kinds of applications or domains where the document based database is more suitable than the relational database? max Probably you shouldn't :-) The second most obvious answer is you should use it if your data isn't relational. This usually manifests itself in having no easy way to describe your data as a set of columns. A good example is a database where you actually store paper documents, e.g. by scanning office mail. The data is the scanned PDF and you have some meta data which

I'm learning traditional Relational Databases (with PostgreSQL ) and doing some research I've come across some new types of databases. CouchDB , Drizzle , and Scalaris to name a few, what is going to be the next database technologies to deal with? Bill Karwin I would say next-gen database , not next-gen SQL. SQL is a language for querying and manipulating relational databases. SQL is dictated by an international standard. While the standard is revised, it seems to always work within the relational database paradigm. Here are a few new data storage technologies that are getting attention