11–20 of 52 posts
I can't comment on the non-relational options as I've never used them, but for your data volume I would expect Postgres to be adequate.
I wouldn't even consider using MySQL. Postgres (aka PostgreSQL) is an industrial-strength open-source RDBMS. I can't comment on the non-relational options as I've never used them, but for your data volume I would expect Postgres to be adequate.
If you decide it makes sense to switch to an rdbms, you should probably consider postgres rather than MySQL.
Yes. It is a very poor choice for your needs.
>to mysql
No. It is a very poor choice in general.
>What other databases
Postgresql obviously. I'm honestly shocked that people are still considering mysql in 2014.
Your use case, running a restaurant is certainly a mixed use case. You'll certainly want to query the latest orders if this is going from the waiter to the kitchen. But yesterday's orders aren't that much important.
As others have mentioned, this data is exactly the kind of data you would store in a relational database. Just be sure to not query for the last 10 orders or something like that. I'm not a real database expert, but I've made this mistake before and as far as I know ordering by date usually means a full table scan.
RDBMS shine when you just store your data and run interesting queries on that data whenever you want to answer a question about that data. Redis is the other way around. If you want to query your data, you'll have to think about your question ahead of time and store it in an appropriate data structure.
What I was wondering is, do you shard your data in different databases? I would guess, every customer should have their on
mysql, mariadb or postgresql would be ok. >> menu_items - string(comma seprated list of all menu items that customer ordered along with their price & Qty) you may prefer to rework the menu_items as an independent table depending on your uses cases and if you don't have strong reason against.
> you may prefer to rework the menu_items as an independent table depending on your uses cases and if you don't have strong ganything against.
I wonder if storing this in an array in postgres would be a good idea?
3) Redis is a great tool in its own right but it's more of a key-value data store than a full fledged database. It's fantastic for caching, tasks queuing or cross application communication.
>moving from redis Yes. It is a very poor choice for your needs. >to mysql No. It is a very poor choice in general. >What other databases Postgresql obviously. I'm honestly shocked that people are still considering mysql in 2014.
>moving from redis Yes. It is a very poor choice for your needs. >to mysql No. It is a very poor choice in general. >What other databases Postgresql obviously. I'm honestly shocked that people are still considering mysql in 2014.