Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I'm trying to find out whether an SQL or no-SQL solution would be better for creating an events database. I'm creating a ticketing system, similar to ticket master. I know that for either database-type storage is the simple part. The deciding factor is the performance of the following queries:

  • Select events by location within a specific date range.
  • Select all events in a given location (city, town, etc.), sort by date.
  • Search for events by keyword, within a specific date range, within a specific location.

Events basically have ID, NAME, LOCATION, VENUE, START DATE, END DATE

In a relational schema I would have an EVENTS table, a DATES table for storing dates separately because events can occur on more than one date and they are repeatable, and a VENUES table from which the event location (country, city, etc) can be cross-referenced.

I have no experience with no-SQL databases, so if you vote for no-SQL please suggest how you see the "schema" being organized and which particular DB.

I hope this question is specific enough. Query performance is the deciding factor.

UPDATE

After more consideration I realize that the question more properly distils to the availability of date/time functions that can facilitate fast date range queries. I know that MySQL and Postgres have such functions. Postgres is even looking a little better at this point in terms of syntax. I don't what NoSQL solutions have to offer regarding this.

share|improve this question

3 Answers 3

up vote 4 down vote accepted

This seems a little outside the scope of a StackExchange question. However.....

NoSQL databases are, typically, build to resolve specific issues with the relational model. The most common issue addressed is scalability. Are you planning to need to handle terabytes of data? However, because they're all designed to address different aspects of certain problems that some applications have with the relational model, there really isn't something you can say about all of them as a whole. Each one is good at something that could be wildly different from what another is good at, while an RDBMS is a much more generalizes database.

The answer I hear from people I trust on this topic is that if you don't already know why you need to abandon a traditional RDBMS for NoSQL, then you almost certainly should stick to an RDBMS. There's a reason it took 30 years before people began to seriously consider data store models beyond the RDBMS. If your queries are requiring features not available in MySQL/MariaDB, you may wish to consider another RDBMS that has a more robust feature set. That could be PostgreSQL, or Oracle, or MS SQL Server.

Your proposed schema here already suits the relational model fairly well. You may need a few junction tables for many-to-many relationships, but I don't think you necessarily will see many of those. If you properly size the DB, properly index your tables, and analyze your common queries -- things you have to do with NoSQL, too -- I don't see that you'd have a huge problem. You may even be able to get away with views for the most common queries.

share|improve this answer
    
Thanks for your answer. I know the system can certainly be modelled comfortably in a relational database. I also am aware that each no-sql solution is different. I was wondering if anyone with any specific knowledge of a particular no-sql DB could cite why that particular DB is good for the solution. –  Ron Apr 20 '13 at 19:37

Basically you a bunch of options here.

  1. Relational
  2. Non-relational
  3. Hybrid (basically relational data with some extended data in a non-relational form, like XML or the like).

Your initial discussion suggests that your data is essentially tabular so a relational model is naturally fits your data.

The second point to keep in mind is that the relational model is well defined mathematically, which helps you repurpose data later for analytics you may not have thought about now.

One of the promises of non-relational models however is a better API. I would suggest that relational models can be encapsulated through a stored procedure interface of you focus on discoverability which can be loosely coupled with your application. You haven't mentioned PostgreSQL but I have written a fair bit on ways to do this on my blog. The first to read is http://ledgersmbdev.blogspot.com/2011/10/introduction-to-soda.html

share|improve this answer

The question, "relational or not" is based on a false assumption that the two are somehow comparable. They are not. The question you're asking might be more constructively phrased as, Should I use a DBMS based on math and logic, one that supports transactions and provides provably correct results, or should I build my own?

Here's a metric for you: if you're not processing millions of transactions per second or adding terabytes of data per day, you're probably not in No-SQL territory. When you get to problems on that scale, it becomes worth it to your employer to pay you to cobble together something very specific to deal with an outsize need. Short of that, likely is $50,000 in hardware will run any SQL DBMS you care to name very quickly, saving gobs of time and money, with greater assurance of correct results and reliable operation.

share|improve this answer
    
Thanks for your answer, but I think this is more of a comment. Yes, I agree that it really isn't a relational vs non-relational question. As I said I think it really boils down to date/time handling and date range queries. What I need are answers outlining the specific advantages of a particular DB. Also I think that SQL vs NoSQL is not a matter of scale, but about the appropriateness for what you are trying to do. So your "metric" really has no bearing on whether to use an SQL vs NoSQL solution. –  Ron Apr 21 '13 at 17:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.