
Mogodb Vs Mysql Decision?
#1
Posted 15 December 2011 - 12:51 PM
I started of sketching out the database schema and it seems fairly straight-forward. I'd create a people table which contains the individual people and then a series of other tables to hold their personal information each in a one-to-many relationship. E.g. Each person can have multiple phone numbers.
All seemed fine until I started thinking through the use cases.
If someone updates their mobile number and saves their details I would essentially have to delete all their numbers and then add them all again because you can't easily tell if details were deleted, updated or inserted to the contact. I think any effort to package the existing ID with each number would simply be messy. So first, is there anything wrong with deleting and re-inserting all one-to-many relationships? It will lead to big gaps in the primary key which I guess can be fixed by calling something like repair etc... For reference this database will have several million users.
This seemed messy so I considered storing the one-to-many relationships as serialised objects within a single table because then I wouldn't have to worry about maintaining FK relationships and having large gaps in the primary keys. This led me to looking at NoSQL solutions as this seems to be basically what they do. I read the mogoDB article from Larry's newsletter and thought it might be worth considering.
Any thoughts?
PS. In general I only have to update or fetch the objects I don't have to search based on a phone number etc...
#2
Posted 16 December 2011 - 8:07 PM
If someone updates their mobile number and saves their details I would essentially have to delete all their numbers and then add them all again because you can't easily tell if details were deleted, updated or inserted to the contact. I think any effort to package the existing ID with each number would simply be messy. So first, is there anything wrong with deleting and re-inserting all one-to-many relationships? It will lead to big gaps in the primary key which I guess can be fixed by calling something like repair etc... For reference this database will have several million users.
Well, first of all, you don't have to do deletes and inserts. You can do REPLACE, which has the same net effect. Or you could just build in the logic to only run an UPDATE query when the user changes something. You absolutely don't want to do anything about the "gaps" in the primary key sequence.
This seemed messy so I considered storing the one-to-many relationships as serialised objects within a single table because then I wouldn't have to worry about maintaining FK relationships and having large gaps in the primary keys. This led me to looking at NoSQL solutions as this seems to be basically what they do. I read the mogoDB article from Larry's newsletter and thought it might be worth considering.
Any thoughts?
I'm not entirely convinced of the merits of non-relational databases, at least not for the general user. But this would seem like a good candidate for MongoDB.
#3
Posted 19 December 2011 - 1:37 AM
Users (id, firstname, lastname, day_of_birth, etc....)
phones (phone_id, user_id*, number)
Email (email_id, user_id*, email)
so on...
To find all emails, numbers, etc, just do a query with "SELECT * FROM table WHERE user_id = $user_id".
To delete/modify a number, use the etc_id like "DELETE from table WHERE some_id = $some_id LIMIT 1/UPDATE table set phone = $variable WHERE some_id = $id". The phone/email/etc id, you add to the URL of a delete/update button link to take you to update/delete.php?id=$variable.
This will make sure data integrity is strong. Use auto_increment on phone_id, email_id and resident_id, and tie them to a user. Make sure phone numbers, emails and residents are unique. They should be anyway. A would recommend a Nation table and city table too if you need to make sure residents have high integrity.
#4
Posted 19 December 2011 - 11:10 AM
#5
Posted 19 December 2011 - 1:09 PM
By the way, I'm thinking of possibly doing a chapter on MongoDB when I do the 3rd edition of my PHP 5 Advanced book next year.
#6
Posted 22 December 2011 - 12:18 PM
#7
Posted 30 September 2012 - 7:55 AM
#8
Posted 1 October 2012 - 6:10 AM
Working on getting you an ebook now...
#9
Posted 3 October 2012 - 6:31 PM
