relational-database

Virtually all POS systems record the price of an item directly to the transactions table at the time of the sale since that price may change at a later date, but the price it sold at should remain the same. I'm wondering how you would setup pricing table(s) that keep a history of price changes, so that you can relate the transactions to that table based on the item and the time it was sold in order to get the correct price? I think anyone who's ever worked with POS systems will understand what I'm talking about here, but if my question is unclear let me know and I will try to explain better. I

I need to add per-province/state taxes to my project. I'm debating whether I should add a many-to-many relationship between Provinces and Taxes, or just add a tax1_name, tax1_rate, tax2_name, tax2_rate to each province. I don't think any place has more than 2 taxes? I will also need to store the tax rate at the time of purchase with each invoice. So my options are add 2 many-to-many tables, or add 8 fields. Which would you go with, and why? Or I could just have 1 combined tax. I don't think it would be too bad if it showed on the invoice as "GST + PST". This would solve the issue with stupid

Having been working with Mongodb and Solr/Lucene, I am starting to wonder why multi-value field for relational databases are (generally) considered an bad idea? I am aware of the theoretical foundation of relational database and normalization . In practice, however, I ran into many use cases where I end up using an meta table of key-value pairs to supplement the main table, such as in the cases of tagging, where I wish I don't have to make multiple joins to look up the data. Or where requirements suddenly changed from having to support an single author to multiple authors per article. So, what

The latest craze in databases seems to be centered around non-relational databases. Why? It seems kind of counterproductive. For example, it makes much more sense to me to express my data in a relational way (example code in Django + SQL for tables): class Post(models.Model): name = models.CharField() created = models.DateTimeField(auto_now_create = True) class Comment(models.Model): text = models.TextField() post = models.ForeignKey('Post') created = models.DateTimeField(auto_now_create = True) SQL: create table post (id int primary key auto_increment, name varchar, created datetime); create

This question is for all NoSQL and specially mongoDB experts out there. I started by designing a relational DB for a project but client wants us to use a DB that can easily scale. To achieve this we have decided to use mongoDB. These days I am having trouble mapping my relational model for NoSQL. I have a users table which has a many-to-many relation with a lot of other tables as illustrated below: I have a few options when converting it for mongoDB: Option 1 (with complete rows in users): users:{ _id:<user_id>, battles:{[battle1, battle2, ...]}, items:{[item1, item2, ...]}, locations:{

Consider 2 or more tables: users (id, firstname, lastname) orders (orderid, userid, orderdate, total) I wish to delete all users and their orders that match first name ' Sam '. In mysql, I usually do left join. In this example userid is unknown to us. What is the correct format of the query? Juan Carlos Oropeza http://www.postgresql.org/docs/current/static/sql-delete.html DELETE FROM orders o USING users u WHERE o.userid = u.id and u.firstname = 'Sam'; DELETE FROM users u WHERE u.firstname = 'Sam'; You can also create the table with ON delete cascade http://www.postgresql.org/docs/current