Hi, Mikael,
Just my 2 cents:
Mikael Carneholm wrote:
Do you really need to create one *DB* per client - that is, is one
schema (in the same DB) per client out of the question?
Sometimes, schemas would work _technically_, but not politically, as a
postgresql user cannot be prevented from
A sodden late night idea ... schemas don't need to have names that are
meaningful to outsiders.
Still, the point about political aspects is an important one. OTH, schemas
provide an elegant way of segregating data.
My $0.02 (not worth what it was)
Greg Williamson
DBA
GlobeXplorer LLC
Hi, Gregory,
Gregory S. Williamson wrote:
A sodden late night idea ... schemas don't need to have names that
are meaningful to outsiders.
Yes, but having schema names like A34FZ37 not only qualifies for
thedailywtf.com, but also tends to produce maintainance nightmares.
And it still allows
Do you really need to create one *DB* per client - that is, is one
schema (in the same DB) per client out of the question? If not, I would
look into moving all reference tables (read-only data, constants and
such) into a common schema (with read permission granted to each
client/role), that way
Hi All,
First thanks for your help everyone!
Mikael Carneholm wrote:
Do you really need to create one *DB* per client - that is, is one
schema (in the same DB) per client out of the question? If not, I would
look into moving all reference tables (read-only data, constants and
such) into
For my application there is very little info I can share. Maybe less
than 10 on 100 actually so I not sure it worth it ...
Ok, so 90% of the tables are being written to - this either means that
your application uses very little constants, or that it has access to
constans that are stored
Mikael Carneholm wrote:
For my application there is very little info I can share. Maybe less
than 10 on 100 actually so I not sure it worth it ...
Ok, so 90% of the tables are being written to - this either means that
your application uses very little constants, or that it has access to
Hi all,
I've been working on my personal project for 3.5 years now. I
developed an ERP system in web/java. Now the people I will work with
suggest to offers it in Saas mode. Which means my customer will connect
to my website and found they ERP software and data there. It's not the
Typically I will have 1db per client and around 150 tables per db. So
since I hope I didn`t work all those year for nothing .. I expect to
have bunch of clients witch means the same amount of db since I have 1
db/client.
Can I hope having several hundred of db on 1 db server? Like 250
On 7/3/06, David Gagnon [EMAIL PROTECTED] wrote:
Can I hope having several hundred of db on 1 db server?Like 250 dbs =250 client = 360 000 tables !!!So is there a limit for the number of db in the db server ?(this spec isnot on the website)What about the performance? Can I expect to have the same
Richard Broersma Jr wrote:
Each table with-in the database is assigned an OID and is located inside the DB
directory. So if
there is a file-system limitation on the number of files with-in a given
directory it would also
be a limit to the number of tables that could be created for each
Hi,
Chris,
In
your deployment,can youput a bit more detail if available? Many
thanks!
My
questions are:
a) How do you resolvethe connection
poolissue?
b) If each client application has many threadsof connections to the
remote server, what is the likely performance penalty with
12 matches
Mail list logo
