On 19 Sep 2010, at 19:26, radhames brito wrote:
For the developer is better to have one database but not for the
clients, some may want their data exported in the future, or you may
need to create extra id number in case some of then sequences for
things like invoices, if you have one db you can use the id field
for invoices. But i havent give much thought to the whole problem,
so is just … an opinion… * runs out and hides behind corner*
Since our main application is CRM and ERP, I’d like to chime in here.
First of all, it’s generally a very bad idea to use IDs as document
numbers, especially with invoices. You might have a few different
scenarios that pop up: customer wants to delete a few invoices (faulty
invoices generated) and turn back the document number, your customer
might want to restart numbering every year, with a document number
like 2010/001, 2010/002, 2011/001, etc. You would create these numbers
in your model and would well be able to scope them properly, however…
That said, we do have a separate database for every customer, for
several reasons, I’ll mention a few.
Although we could scope everything on the customer, but given the
total amount of data involved across all accounts, it would have a
dramatic impact on performance over time, even with proper indexes.
Also, since we are storing the data of direct competitors (our
customers are in the same market segment in our already small country)
we found that during presales the question about keeping data separate
always arose. Again, a good test suite could and should avoid one
customer seeing another one’s data, just like Blinksale does it, but
prospects might not see it that way so easily.
There were a few more factors that made us decide to keep data
separate, it’s up to you to decide the best choice depending on your
It’s a trivial task to make sure migrations run across all databases
on deploy btw, you just have to tinker with the default Capistrano
script a bit and you’re done.
Peter De Berdt