PostgreSQL: database o schema?

[francesco.tonucci]

So che è una domanda OT, ma è una cosa urgente e magari potete aiutarmi.

Sto realizzando un'applicazione all'interno della nostra intranet Plone,
che, come la maggior parte delle applicazioni future, si appoggia ad un
database (in questo caso PostgreSQL).

Molto probabilmente, tutte queste applicazioni dovranno utilizzare
informazioni riguardanti gli utenti e la struttura (organigramma) dei
nostri uffici. Ho pensato perciò di utilizzare un db a sè per
memorizzare queste informazioni condivise. Al momento quindi ho:

- utenti -> db generale (con info condivise)
- tempi_medi -> db specifico dell'applicazione

Il problema è che postgre non permette di fare query su db diversi
(almeno nativamente) e i due db di cui sopra (ma la cosa potrebbe valere
anche per le successive applicazioni) sono strettamente connessi.

Detto questo mi chiedo se è meglio continuare sulla linea dei db
diversi, oppure creare un unico maxi db, ad esempio denominato
"intranet", con all'interno tanti schemi, uno per ogni applicazione, più
quello generico.

A me sembra più logico mantenere separati i db, ma vorrei un parere più
esperto, considerando anche le prestazioni di postgre nel momento in cui
saranno presenti ulteriori applicazioni e con circa 50 connessioni
contemporanee.

Grazie.


[francesco_tonucci.vcf]

---

begin:vcard
fn:Francesco Tonucci
n:Tonucci;Francesco
org:C.C.I.A.A. di Pesaro e Urbino
adr;dom:;;C.so XI Settembre, 116;Pesaro;PU;61100
email;internet:[hidden email]
title:Referente informatico
tel;work:0721 357 210
tel;cell:346 3950985
x-mozilla-html:TRUE
version:2.1
end:vcard

---

_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html

[SauZheR at gOOgle]

Se devi fare query per mettere in join tabelle di db diversi stai fresco.

Puoi pero' all'interno di zope avere 2 istanze separate dell'adapter
dB (ZPsycopgDA ad es.) per ciascun database.

Fare quindi zsqlmethod separati, con query separate, e poi incrociare
i dati via script python. Non sara' il massimo dell'efficienza, ma
funzionerebbe,.

bye

Il 23 settembre 2009 10.02, Francesco Tonucci
<[hidden email]> ha scritto:

> So che è una domanda OT, ma è una cosa urgente e magari potete aiutarmi.
>
> Sto realizzando un'applicazione all'interno della nostra intranet Plone,
> che, come la maggior parte delle applicazioni future, si appoggia ad un
> database (in questo caso PostgreSQL).
>
> Molto probabilmente, tutte queste applicazioni dovranno utilizzare
> informazioni riguardanti gli utenti e la struttura (organigramma) dei nostri
> uffici. Ho pensato perciò di utilizzare un db a sè per memorizzare queste
> informazioni condivise. Al momento quindi ho:
>
> - utenti -> db generale (con info condivise)
> - tempi_medi -> db specifico dell'applicazione
>
> Il problema è che postgre non permette di fare query su db diversi (almeno
> nativamente) e i due db di cui sopra (ma la cosa potrebbe valere anche per
> le successive applicazioni) sono strettamente connessi.
>
> Detto questo mi chiedo se è meglio continuare sulla linea dei db diversi,
> oppure creare un unico maxi db, ad esempio denominato "intranet", con
> all'interno tanti schemi, uno per ogni applicazione, più quello generico.
>
> A me sembra più logico mantenere separati i db, ma vorrei un parere più
> esperto, considerando anche le prestazioni di postgre nel momento in cui
> saranno presenti ulteriori applicazioni e con circa 50 connessioni
> contemporanee.
>
> Grazie.
>
>
> _______________________________________________
> Plone-IT mailing list
> [hidden email]
> http://lists.plone.org/mailman/listinfo/plone-it
> http://www.nabble.com/Plone---Italy-f21728.html
>

--
  bye
SauZheR
************************************
l'iterazione è umana...
la ricorsione, Divina!
************************************
reply to: sauzher AT gmail DOT com

_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html

[Claudio Battaglino]

Francesco Tonucci wrote:
> A me sembra più logico mantenere separati i db, ma vorrei un parere
> più esperto, considerando anche le prestazioni di postgre nel momento
> in cui saranno presenti ulteriori applicazioni e con circa 50
> connessioni contemporanee.

Secondo me, se la tua applicazione ha la necessità di effettuare query
su tabelle di database diversi è meglio migrare tutte le tabelle su un
unico database. In questo modo infatti, si sfruttano al meglio la
potenza e le ottimizzazioni del dabase che utilizzerai (Postgres, MySql
o altro).
Inoltre sarà più facile effettuare il backup dei dati  e saranno più
agevoli il debug e la manutenzione dell'applicazione.


Se la tua applicazione raramente avrà la necessità di intrecciare dati
di tabelle di database diversi, allora puoi pensare di utilizzare
database diversi.

cld



_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html

[francesco.tonucci]

Some javascript/style in this post has been disabled (why?)

Grazie del consiglio.
Mi chiedo però se sia la prassi corretta avere i dati diciamo di 10 (o anche più) applicazioni diverse su uno stesso db...



Claudio Battaglino ha scritto:

Francesco Tonucci wrote:
  

A me sembra più logico mantenere separati i db, ma vorrei un parere
più esperto, considerando anche le prestazioni di postgre nel momento
in cui saranno presenti ulteriori applicazioni e con circa 50
connessioni contemporanee.
    

Secondo me, se la tua applicazione ha la necessità di effettuare query
su tabelle di database diversi è meglio migrare tutte le tabelle su un
unico database. In questo modo infatti, si sfruttano al meglio la
potenza e le ottimizzazioni del dabase che utilizzerai (Postgres, MySql
o altro).
Inoltre sarà più facile effettuare il backup dei dati  e saranno più
agevoli il debug e la manutenzione dell'applicazione.


Se la tua applicazione raramente avrà la necessità di intrecciare dati
di tabelle di database diversi, allora puoi pensare di utilizzare
database diversi.

cld


  

_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html

[francesco_tonucci.vcf]

---

begin:vcard
fn:Francesco Tonucci
n:Tonucci;Francesco
org:C.C.I.A.A. di Pesaro e Urbino
adr;dom:;;C.so XI Settembre, 116;Pesaro;PU;61100
email;internet:[hidden email]
title:Referente informatico
tel;work:0721 357 210
tel;cell:346 3950985
x-mozilla-html:TRUE
version:2.1
end:vcard

---

_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html

[Yuri-11]

Francesco Tonucci ha scritto:
> Grazie del consiglio.
> Mi chiedo però se sia la prassi corretta avere i dati diciamo di 10 (o
> anche più) applicazioni diverse su uno stesso db...

Se le query sono incrociate, significa che la tua applicazione ha come
modello una base di dati più ampia.

 Cmq, Postgres supporta gli schemi:


http://www.postgresql.org/docs/current/static/ddl-schemas.html

Oppure usare dblink

http://www.postgresql.org/docs/current/static/dblink.html

"To use the dblink:

   1. In your *postgres* server you should find a file *dblink.*sql**.
      In my beta installation is in *share/*postgresql*/contrib*. It is
      the installation for the dblink contrib module that usually is
      already compiled in. It will create a lot of dblink functions.

   2. on database2 create a function nammed db_datbase1() which returns
      "dbname=database1" (if you need a login use "dbname=database1
      password=xxx", you can also specify host= port= to connect in a
      remote *postgresql* database)

   3. now execute the *sql*:
      select * from dblink(db_database1(), 'select "id", "name", "time"
      from pr_1') as pr_1("id" integer, "name" text, "time" time)
      then you will see the table "pr_1" on the datbase2 "

:)

>
>
>
> Claudio Battaglino ha scritto:
>> Francesco Tonucci wrote:
>>  
>>> A me sembra più logico mantenere separati i db, ma vorrei un parere
>>> più esperto, considerando anche le prestazioni di postgre nel momento
>>> in cui saranno presenti ulteriori applicazioni e con circa 50
>>> connessioni contemporanee.
>>>    
>>
>> Secondo me, se la tua applicazione ha la necessità di effettuare query
>> su tabelle di database diversi è meglio migrare tutte le tabelle su un
>> unico database. In questo modo infatti, si sfruttano al meglio la
>> potenza e le ottimizzazioni del dabase che utilizzerai (Postgres, MySql
>> o altro).
>> Inoltre sarà più facile effettuare il backup dei dati  e saranno più
>> agevoli il debug e la manutenzione dell'applicazione.
>>
>>
>> Se la tua applicazione raramente avrà la necessità di intrecciare dati
>> di tabelle di database diversi, allora puoi pensare di utilizzare
>> database diversi.
>>
>> cld
>>
>>
>>  
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Plone-IT mailing list
>> [hidden email]
>> http://lists.plone.org/mailman/listinfo/plone-it
>> http://www.nabble.com/Plone---Italy-f21728.html
> _______________________________________________
> Plone-IT mailing list
> [hidden email]
> http://lists.plone.org/mailman/listinfo/plone-it
> http://www.nabble.com/Plone---Italy-f21728.html

_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html

[Claudio Battaglino]

Francesco Tonucci wrote:
> Grazie del consiglio.
> Mi chiedo però se sia la prassi corretta avere i dati diciamo di 10 (o
> anche più) applicazioni diverse su uno stesso db...
>

Dipenda dall'architettura complessiva del sistema che stai realizzando e
da quanto sono correlate queste applicazioni
E' normale che più applicazioni condividano un unico database se queste
applicazioni richiedono di effettuare join su tutte queste tabelle.

cld




_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html

[garva]

Francesco Tonucci ha scritto:

> So che è una domanda OT, ma è una cosa urgente e magari potete aiutarmi.
> Sto realizzando un'applicazione all'interno della nostra intranet
> Plone, che, come la maggior parte delle applicazioni future, si
> appoggia ad un database (in questo caso PostgreSQL).
> Molto probabilmente, tutte queste applicazioni dovranno utilizzare
> informazioni riguardanti gli utenti e la struttura (organigramma) dei
> nostri uffici. Ho pensato perciò di utilizzare un db a sè per
> memorizzare queste informazioni condivise. Al momento quindi ho:
> - utenti -> db generale (con info condivise)
> - tempi_medi -> db specifico dell'applicazione
> Il problema è che postgre non permette di fare query su db diversi
> (almeno nativamente) e i due db di cui sopra (ma la cosa potrebbe
> valere anche per le successive applicazioni) sono strettamente connessi.
> Detto questo mi chiedo se è meglio continuare sulla linea dei db
> diversi, oppure creare un unico maxi db, ad esempio denominato
> "intranet", con all'interno tanti schemi, uno per ogni applicazione,
> più quello generico.
> A me sembra più logico mantenere separati i db, ma vorrei un parere
> più esperto, considerando anche le prestazioni di postgre nel momento
> in cui saranno presenti ulteriori applicazioni e con circa 50
> connessioni contemporanee.
>

Ciao,

io ho avuto modo di usare sqlrelay http://sqlrelay.sourceforge.net/
che consente di collegare più db contemporaneamente.

in pratica sqlrelay si collega a n db e plone si collega a sqlrealy
in qualche modo, se non ricordo male, è possibile eseguire
sql su più db

http://sqlrelay.sourceforge.net/sqlrelay/router.html

ma non credo join tra tabelle che stanno su db diversi

giuseppe



_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-it
http://www.nabble.com/Plone---Italy-f21728.html