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.
After further consideration, I realize the question more properly distills to the availability of date/time functions that can facilitate fast date range queries. I know MySQL and PostgreSQL have such functions. PostgreSQL is even looking a little better at this point in terms of syntax. I don't know what NoSQL solutions have to offer regarding this.
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.