On Sep 19, 8:59 pm, Marnen Laibow-Koser wrote:
> Robert Pankowecki wrote:
> > I can see some other advantages.
> > You can easily split your application into multiple servers.
> Any decent DB server can do that with one DB.
I know. I meant the situation when there are so many data that you
want t
Robert Pankowecki wrote:
> I can see some other advantages.
>
> You can easily split your application into multiple servers.
Any decent DB server can do that with one DB.
> That
> gives you the ability to upgrade clients to new application step by
> step instead of migrating whole bunch of dat
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 y
I can see some other advantages.
You can easily split your application into multiple servers. That
gives you the ability to upgrade clients to new application step by
step instead of migrating whole bunch of data at the same time. Some
clients want to upgrade today some in next week.
The code to
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
m
Robert Pankowecki wrote:
> On Sep 19, 1:46�am, Marnen Laibow-Koser wrote:
>> Don't do that. �I saw the other thread, and I think you were given bad
>> advice. �You almost always want one big DB for the whole thing. �It's
>> usually easier to deal with.
>
> Any reason why it is wrong to do that ?
On Sep 19, 1:46 am, Marnen Laibow-Koser wrote:
> Don't do that. I saw the other thread, and I think you were given bad
> advice. You almost always want one big DB for the whole thing. It's
> usually easier to deal with.
Any reason why it is wrong to do that ? Why is it easier in your
opinion?
giorgio wrote:
> I asked on another thread about adding an "organisation_id" across the
> whole database to effectively give a separate database for different
> organisations who use the app.
>
> The other way of doing it would be to have one app but different
> databases depending on the subdomai
8 matches
Mail list logo
