Newsgroup: it.comp.os.linux.sys
Titolo: Quale DB e' il piu' indicato?

Ciao a tutti!
Visto che mi hanno promosso sul campo DB-Administrator (nonostante abbia
detto piu' volte di essere a malapena capace di mettere insieme una query
SQL), eccomi qui a chiedere un paio di informazioni...
Attualmente usiamo un DB MySQL con tabelle MyISAM. Volevo sapere se c'era
qualcosa di meglio...
Il problema, ovviamente, e' la quantita' di dati. Attualmente abbiamo 127
tabelle con circa 100.000.000 di record in totale (spazio su disco
occupato: circa 20GB).
Ma queste cifre sono destinate a crescere esponenzialmente... :(
Ovviamente a noi serve poter accedere a questi dati il piu' rapidamente
possibile (in lettura! La scrittura puo' anche prendere un paio di secondi
e non muore nessuno!).
Ah, gia'! In lettura dobbiamo fare parecchie JOIN tra le varie tabelle...
Domanda: usiamo il DB giusto? Magari altri sono piu' performanti? Oppure
il DB e' il migliore, ma potrebbe migliorare le prestazioni con altri tipi
di tabelle? Ci sono altri trucchi per migliorare le prestazioni?
In pratica: qualcuno ha un'idea di cosa mi tocca fare, visto che io
proprio non ce l'ho? :(
Grazie mille a tutti per i vostri consigli!
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 proprio non ce l'ho? :(
Scusa, ma che in ca%%o di azienda lavori?
-- 
Posted via a free Usenet account from 
http://www.teranews.com

 Ma queste cifre sono destinate a crescere esponenzialmente... :(
La quantità di dati non dovrebbe essere un problema.
Normalizza il database se non lo è già e indicizza i campi su cui 
intendi fare le join. Ora i tempi di esecuzione delle query come sono?
Per valutare l'efficienza degli indici nelle tue query usa explain. Esempio:
$ mysql -uroot
 > use mysql;
 > explain select A.*, B.* from db as A, user as B where A.user=B.user;
Credo che ci siano dei tutorial on-line su come interpretarne l'output.

 Ma queste cifre sono destinate a crescere esponenzialmente... :(
In azienda superiamo i 100GB di file di dati. Utilizziamo esclusivamente
Oracle (10.2) e devo dire che è molto affidabile e veloce. Non ho test
comparativi da sottoporti, ma solo la mia esperienza. Ovviamente è a
pagamento.
Ciao

 posso dirti 
http://www.soft-land.org/faq/icsdfaq
 ?
Sto leggendo! Grazie!
Ciao


 pagamento.
Capisco. Beh, l'uso di software a pagamento non e' escluso a priori.
Ovviamente, visto il costo osceno di Oracle, devo dare motivazioni
adeguate per poter convincere il capo a cacciare l'assegno.
Altrimenti magari lo compra anche, ma poi mi detrae il costo dallo
stipendio... :)
Ciao


Con tabelle nell'ordine dei 2 giga l'una qui usiamo Oracle per alcune
procedure che acquistiamo dall'esterno.
Invece per diverse procedure interne ho installato FirebirdSQL su una
macchina con OS a 64 bit ed il DBA mi ha detto che non nota differenze
sostanziali di prestazioni sull'SQL standard.
Tobe



Molto interessante.
Giusto per curiosità, che versione di oracle avete e che tipo di attività
viene fatta sul db?

 occupato: circa 20GB).
Mi sa che l'unica e` provare.
Fai un dump SQL e importalo prima in MySQL e poi in altri DB e fai un po' 
di prove.
Senza andare a provate Oracle, io ti consiglio PostgreSQL e Firebird, che 
da quanto so si comportano meglio di MySQL in caso di multiutenze connesse.
Bye.

 viene fatta sul db?
L'applicativo esterno che utilizziamo è certificato per Oracle 10.2.
Le applicazioni interne sono scritte in Java e la maggior parte delle
operazioni sono letture con join fra diverse tabelle (una dozzina).
In un solo caso il DBA mi ha fatto notare una notevole differenza a
favore di Oracle, ma mi sembra di ricordare che fosse dovuta ad una
funzione SQL non standard in una stored procedure.
Per la cronaca il server è un doppio dualcore con 4 GB di RAM e 4 dischi
15Krpm in RAID 10 HW.
Tobe

 di prove.
Occhio che, a meno che le query non siano banalissime, occorrerà
probabilmente riscriverle per adattarle al nuovo DB.
-- 
CdL

 secondi e non muore nessuno!).
Beh, se parli cosi', in questo senso LDAP e' superiore a qualsiasi DB 
relazionale.
... ovviamente sto parlando di ldap senza lo stupido backendo con db 
relazionale (che e' la cosa piu' demente di questo mondo) e ovviamente 
non sto parlando di nemmeno di openldap. 
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 relazionale.
Che è un po' come dire che la Ferrari è superiore a qualsiasi marca di
champagne...
-- 
CdL



No. E' come dire che per guadare un fiume una land rover e' superiore a 
qualsiasi ferrari.
Tu certi lavori puoi farli - indifferentemente - con LDAP e con SQL.
Cerca di non pensare a ldap esclusivamente come strumento per la tua 
rubrica condivisa.


 rubrica condivisa.
mi spiego meglio: chiediti come mai il tuo address book non e' un client 
SQL ed e' invece un client ldap (nonostante sia fattibilissimo anche con 
SQL). 
Dipende solo ed esclusivamente da quello che devi fare con il DB. Ma 
quello che deve fare Luca noi non lo sappiamo.
LDAP e' estremamente piu' performante e - tranne che non ci metti il 
backend mysql - puoi avere anche milioni di entries... 


 relazionale (che e' la cosa piu' demente di questo mondo)
In teoria si', in pratica no, sopratutto quando usi un database come MySQL
che e' ottimizzato per le letture e non per le scritture e non ha costi
reali di apertura di connessione.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 costi reali di apertura di connessione.
guarda, c'era un vecchio post dei developer di openldap dove questa 
accoppiata veniva sconsigliato vivamente (purtroppo non riesco piu' a 
trovarlo).
Ad ogni modo, facciamo un altro ragionamento.
Il buon vecchio Netscape DS, aveva come backend ldbm (gia' ai tempi dei 
tempi supportava il multi-mastering in read-write, mentre in openldap 
questa feature e' ancora sperimentale e se invece di pensare alle 
stronzate pensassero a queste cose forse sarebbe meglio)
Poi Netscape DS si e' "forkato" in iplanet, sunds, fedoraDS.
recentemente il backend SunDS e' stato migrato da ldbm al bdb di 
sleepycat.
Perche' non lo hanno migrato ad un DB relazionale?


 (
luca...@lucabert.de
)
=============================================================
But wait, you say. You're already using an Oracle, Sybase, Informix, or 
Microsoft SQL database to store much of that same data. How is LDAP 
different? What makes it better? Read on.
http://www.ldapman.org/articles/intro_to_ldap.html
=============================================================
LDAP vs relational database
Typically, when I ask enterprise developers where they'll store 
application data the response is immediate, a relational database. The 
directory server isn't even an afterthought. There's a long laundry list 
of reasons why: no one gets fired for choosing Oracle, its already there, 
familiarity with SQL, plethora of RDBMS tools, LDAP writes are slow, JNDI 
interface - are you kidding?!... While all of these are legitimate 
retorts, LDAP, and in particular OpenDS, bring with it clear advantages 
for certain classes of applications.
It's a database! LDAP isn't just a dumping ground for user profile data, 
it's a full-fledged hierarchical database. If your data is modeled in a 
parent-child fashion, not unusual in a XML world, then LDAP might be a 
better fit. LDAP data modeling is very different than relational modeling 
though at a simplistic level you might map tables to entries and columns 
to attributes.
http://blogs.sun.com/treydrake/entry/ldap_vs_relational_database
http://blogs.sun.com/treydrake/entry/ldap_vs_relational_database_part
=============================================================


> Scusa, ma che in ca%%o di azienda lavori?
nella classica azienda italiana, direi.
-- 
Spolvera la mia email per rispondermi


 proprio non ce l'ho? :(
Comprati High Performance MySQL di O-Really che fai prima IMHO.
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

 nella classica azienda italiana, direi.
ma LOL. Lavora a Dresda. haihaihai....


 nella classica azienda italiana, direi.
No, l'Italia l'ho lasciata da un pezzo...
Ma anche in Germania, sopratutto (come nel mio caso) nelle ditta che NON
si occupano di informatica e che hanno solo un tapino che si occupa
dell'infrastruttura informatica, c'e' ogni tanto l'idea che chi schiaccia
i tasti sappia fare tutto... :(
E non ditemi che in Italia non e' cosi' che tanto non ci credo! :)
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 


 Perche' non lo hanno migrato ad un DB relazionale?
Perche' LDAP ha una struttura di dati non relazione ma gerarchica, quindi
quando sei su milioni di record non ti conviene. Ma se hai numeri piu'
piccoli, usare un back-end come MySQL ti porta a due vantaggi, uno che hai
un uniformita' di procedure di backup, due che i tuoi sviluppatori sanno
gia' lavorarci. 


 due che i tuoi sviluppatori sanno gia' lavorarci.
i mi prendo sviluppatori ldap, mica sviluppatori sql :P


 E non ditemi che in Italia non e' cosi' che tanto non ci credo! :)
qui sono addirittura convinti che *solo* in Italia funziona cosi :P
e si vede che non hanno visto i manager inglesi che ho visto io... che 
tecnologicamente parlando sono dei broccoli come quelli italiani :)


 Perche' non lo hanno migrato ad un DB relazionale?
Oh, ma questo non l'ha fatto nemmeno OpenLDAP, eh :)
Enrico

 di tabelle? Ci sono altri trucchi per migliorare le prestazioni?
http://devloop.org.uk/documentation/database-performance/
Enrico

 Ciao a tutti!
Luca, personalmente ti ritengo una brava persona competente, pero` piu`
andiamo avanti e piu` vedo che hai un brutto vizio: posti qui tutto
quello che ti passa. Per farti un esempio, questo thread era piu`
consono su it.comp.software.database (che poi, probabilmente, e` seguito
da molte delle persone che si trovano qui e` un altro discorso...)
Enrico

 Ciao, Micky
Questo mi ricorda una certa persona che parlando di esigenze simili e
preferendo comunque oracle come db (che in ogni caso richiede hardware
pesante e di saperlo configurare bene, richiede partizioni dati, partizioni
per la flash area, ecc.) parlava di un fine tuning di mysql, tipo spostare
i file di sort (che con quella mole di dati probabilmente mysql usa) su una
partizione di un altro disco, modifiche proprietarie (se mi ricordo bene
servivano perché' avevano una marea di accessi contemporanei al db e mysql
non si comportava bene in quelle situazioni), ecc., e alla fine le
prestazioni erano simili a quelle di oracle.
Personalmente ho provato la versione free e limitata di oracle 10gx e l'ho
trovato un db piuttosto impegnativo da configurare e mantenere, un po'
esoso nell'uso delle risorse, tools di manutenzione pesanti e limitati,
piuttosto delicato, backup on line di dimensioni esagerate, e l'ho trovato
piuttosto rapido e efficiente (ma è obbligatorio lasciare il db in case
SENSITIVE (e questo a volte può essere un dramma) o mettersi a costruire
degli indici appositi per ogni tabella).
Poi abbiamo avuto problemi con il client win odbc instant client che ha
problemi con i caratteri, non è ole odbc e quindi non usabile da
applicazioni ms office o altre.
Problemi risolti usando il pacchetto/setup completo odbc/dbo/oledb/ecc. con
l'attenzione di configurare a mano nella voce dell'odbc nel registro di win
la lingua da usare, altrimenti l'ordinamento segue logiche ... forse
metatifisiche, sicuramente non alfabetiche.



aggiungo: e nemmeno postifix, e nemmeno il mail server di sun e nemmeno 
exchange server, e per fortuna :)


 i mi prendo sviluppatori ldap, mica sviluppatori sql :P
Io invece solo sviluppatori che lavorino per la NASA, cosi' sono sicuro che
sono bravi e non mi devo preoccupare del loro livello tecnico e dei costi di
aggiornamento professionale.


 costi di aggiornamento professionale.
Scherzavo. Mi rendo conto che esistono piu' gente che conosce PLSQL che 
non gente che conosce LDAP ^_^


 aggiungo: e nemmeno postifix
Beh, postfix può usare un db relazionale come backend utenti...

 aggiungo: e nemmeno postifix
Errato, Postfix puo` appoggiarsi ad un database relazionale :)
Enrico

 casa per i fatti miei).
OpenLDAP permette di creare repliche in due secondi. Praticamente sul
master definisci gli slave su cui devi creare la replica, e sugli slave
definisci da quale master devono accettare le repliche
Enrico
P.S. ovviamente se hai degli schemi da una parte devi averli anche
dall'altra



Beh questa mi sembrava una ovvieta' talmente scontata che non mi 
aspettavo nemmeno che la scrivessi....
anche openldap *PUO'* appoggiarsi a un backend sql.
Il punto e' che *non* e' che - come openldap - non e' stato migrato.




ma vah! vuoi vedere che non lo sapevo.
usatele queste cose ... .... se ritenete che siano utili usatele pure.


 
bravo, parlando di master e salve, ti sei rispostoa da solo: OpenLDAP non 
supporta il multi-mastering (se non come feature alpha).
SunDS supporta 4 master in read-write e tanti slave quanti ne vuoi.
Active Directory supporta teoricamente un numero imprecisato di 
master.... e openldap supporta il backend sql (LOL).


 usatele queste cose ... .... se ritenete che siano utili usatele pure.
Se serve, certamente.

 Se serve, certamente.
a cosa? :)
p.s.: il mail server di Sun fa parte della suite JES e ha il suo backend 
sul server LDAP (e quindi su un db transazionale). Il server Exchange di 
Microsoft hai  suoi DB interni sicuramente transazionali anche questi.
A cosa serve questo db relazionale su un mail server? Ci fate i trigger 
sulle mail, le stored procedure? O magari e' sufficiente e piu' veloce il 
DB Berkeley, gia' in uso in postfix (se usi postfix: man postalias, 
postmap, newaliases). Questi ultimi sono dei db anch'essi piu' 
performanti e piu' utili di un db transazionale.


 piu' performanti e piu' utili di un db transazionale.
piu' performanti e piu' utili di un db *relazionale*


 Questo mi ricorda una certa persona che parlando di esigenze simili e
Uso MySQL perché mi tocca, non mi piace, ma visto che anche a chi ha
posto la domanda è capitato di dover usare MySQL tanto vale che si legga
quel libro, fatto molto bene secondo me, e veda che riesce a tirar
fuori, se poi le prestazioni non migliorano penserà a cambiare motore,
ma se le prestazioni risultassero accettabili evitare di fare modifiche
alle applicazioni che sono già state scritte per girare con MySQL è
sicuramente una strada da cercare di percorrere.


 quel libro, fatto molto bene secondo me, e veda che riesce a tirar
]zac[
Forse non era chiaro, ma intendevo sostenere la tua proposta e anche far
notare che usare oracle non vuol dire garantirsi immediate e facile aumenti
di prestazioni, di idiosincrasie (o di feature come le chiamano nel mondo
oracle) ne ha varie, come il case sensitive, problemi con campi con nome
uguale a comandi, linguaggio sql esteso ma particolare (come per altri db,
ma con meno attenzione alla compatibilità), ecc. .

 A me non mi risulta.
Presumo EnterpriseDB, ma non ne sono certo.


 O magari e' sufficiente e piu' veloce il DB Berkeley, 
Il cielo ce ne scampi e liberi.
Comunque vorrei farti notare che su questo ng si parla di Linux in specifico
e di GPL e compatibili in generale, non di Sun.


 supporta il multi-mastering (se non come feature alpha).
Cosa c'entra. Semplicemente, davo risposta ad un tuo quesito (ovvero se
OpenLDAP supportasse o meno le repliche e come). Che altri prodotti
siano piu` potenti e completi (FedoraDS in primis) e` strasaputo, ma
questo non significa dover per forza sputare su quello meno completo 
(soprattutto considerando che il suo sporco lavoro lo fa decentemente)
Enrico

 sulle mail, le stored procedure?
Attenzione, Postfix utilizza un backend relazionale (PostgreSQL o MySQL)
solo per la gestione utenti, e non per immagazzinarci le email. Per
quello esiste dbmail
Enrico
P.S. dei trigger che permettono il backup dei dati di un utente (le
cosiddette tabelle di audit) non sarebbero male come idea...

 specifico e di GPL e compatibili in generale, non di Sun.
Giustissimo, pero'...
FedoraDS e' al 99% uguale a SunDS (*). Per quel che so FedoraDS usa 
sempre ldbm, e supporta un numero minore di repliche master (ma non 
ricordo bene).
Pertanto quello che dico su SunDS, vale alla stessas maniera anche per 
FedoraDS.
(*) mi pare di capire che sunds ora si chiami: OpenDS




ok quoto tutto.
p.s.: sapevo che openldap supportava la replica master-slave. Devo 
conoscere il mio nemico ^_^


 FedoraDS.
Allora dillo per Red Hat Directory Server :)


 dintorni, quindi preferirei proprio evitare.
Senza offesa per nessuno, ma se esporto il db LDAP via NFS, allora tutti
i problemi che ne conseguono me li merito senza indugio
Enrico

 (se usi postfix: man postalias, postmap, newaliases). 
Rotfl.



wiplash, cosa ti e' chiaro e cosa non ti e' chiaro della differenza tra 
'db' transazionale e db relazione?
Secondo te sono 2 cose diverse o pensi che uno e' migliore dell'altro?
Cosa non ti e' chiaro del funzionamento dei file db dei server di posta? 
Sei convinto che un db relazionale sarebbe piu' efficiente?
Spiegami come :) Tramite le stored procedures?


 Allora dillo per Red Hat Directory Server :)
e va bene ^_^




Non ho idea di questa situazione. Comunque quel db e' sviluppato 
attivamente e i bug vengono corretti.


 'db' transazionale e db relazione?
Non saprei, vuoi spiegarmelo tu?
Ma ti spiego perchè rido, visto che non ci arrivi.
Se utilizzo postfix, pensi che io abbia bisogno del tuo illuminato
suggerimento per scoprire cosa fanno e su quali formati lavorano
postalias, postmap e newaliases?
Consiglio piuttosto a *te* di leggere quei man, così, magari, scoprirai
che quel  [file_type:] ha un significato...



chiaro che un significato ce lo ha.
Ti lascio l'ultimo compitino per casa, su come realizzare un buon mail 
server ^_^ ... magari pure con SSL
man postconf (e cerca ldap)
man ldap_table
no, non mi dire che adesso ti sta venendo il dubbio che una query su ldap 
o su un db transazionale potrebbero essere addirittura piu' veloci di una 
query su db relazionale, e che i trigger in fondo in fondo non ti servono 
a un ca$$o ^_^
siamo punto e a capo: mi devi spiegare a cosa serve un mail server su 
SQL. E la tua situazione e' molto peggiorata dal momento in cui ho 
scoperto che postfix supporta anche ldap ^_^


 attivamente e i bug vengono corretti.
E` un problema strarisaputo, e sinceramente ancora non ho capito se il
problema sia dovuto a bdb o a nfs. Fatto sta che i tizi di Subversion
hanno preferito deprecare bdb in favore di fsfs[1]
Enrico
[1] a dire il vero non sono sicuro che sia il motivo, ma probabilmente
e` uno dei motivi

 scoperto che postfix supporta anche ldap ^_^
In sintesi, tu un man di postfix non l'avevi mai fatto e davi consigli a me.
Rotfl.

 se non ne puoi sfruttare le sue caratteristiche piu' importanti?
E' per me una questione di semplicita'. Se vuoi usare un server LDAP, devi
installarlo, configurarlo, manutenerlo, quindi hai i suoi propri problemi di
sicurezza, le sue porte da aprire sui firewall, i suoi backup da gestire, il
suo tuning da fare. Se hai 100k record LDAP e' un investimento che e'
dovuto, se ne hai di meno cerchi di ricondurti al caso precedente. Posso
dirti che conosco almeno un caso in cui ci sono decine di migliaia di record
LDAP e stanno pensando di passare a MySQL per evitare di avere colli di
bottiglia umani (uno solo che ci sa mettere mani sopra per aggiungere
record). 


 a un ca$$o ^_^
se vuoi te lo dico io, che ho su DB i dati "di servizio" (utenti,
transport, configurazioni varie) letti in contemporanea da una dozzina
di postfix.
Precedentemente l'attuale implementazione, tutti i sistemi lavoravano
solo su file locali, con un marasma di script che si occupavano della
propagazione dei dati. I problemi conseguenti erano asincronie, tempi
non nulli di propagazione delle configurazioni, eccessiva complessità
delle propagazioni stesse, eccessiva rigidità del tutto, dato che ad
ogni minima variazione di struttura toccava andare a metter mano agli
script di propagazione, oltre che alle configurazioni dei server.
Quindi: perchè non dbd e basta? Risposta: perchè bdb non gestisce
accesso concorrenziale da macchine diverse[1]. Ed è già un buon motivo...
[1] Ecco perchè qualcuno ha citato il problema del mancato dunzionamento
di bdb su NFS: non è che uno lo fa per farsi del male...
Si necessitava di cambiare, e ovviamente la domanda che veniva dopo era:
SQL o LDAP?
La scelta di andare su SQL è stata parecchio meditata (prima di
scegliere tra uno e l'altro abbiam fatto quasi 8 mesi di testing e
sviluppo) e principalmente legata al fatto che SQL, inevitabilmente, fa
*già* parte della struttura dei servizi. Il che significa servizi in
meno da gestire e knowhow in meno da mantenere, il che non mi par poco.
Inoltre, proprio per il fatto che SQL c'è già, avere anche questi dati
su SQL significa garantire una migliore (o quantomeno più semplice)
tracciabilità delle relazioni tra i record dei DB su cui si appoggiano i
mailserver con quelli necessari al resto dell'infrastruttura di
provisioning (che a sua volta deve "agganciarsi" alle basi-dati
anagrafiche, di fatturazione, ecc.), e anche questo non è poco.
Data la tipologia di accesso alla base dati che effettua il mailserver
(accesso in sola lettura, e tipicamente sempre le stesse 4 query in
croce) la differenza di prestazioni tra un mysql su myisam e un LDAP su
bdb (o equivalente) è di fatto nulla, e quindi non rappresenta una
grossa vincolante.
Quanto alla scalabilità, è a sua volta lineare: se mai raggiungessi il
massimo numero di query/sec gestibili dal DB di backend, sarebbe lavoro
banale configurare i vari postfix per interrogare un pool di server in
replica. Quindi anche qui, non c'era ragione vincolante per andare su LDAP.
Per dare ragione di una cosa, effettivamente non faccio uso in alcun
modo di trigger o stored procedure, ma non lo escludo per il futuro, e
ritengo altresì che in effetti possano rappresentare un plus ultra
anzichenò.
Se ora come ora voglio stabilire dei "casi" in cui i mailserver devono
comportarsi diversamente, sono obbligato a implementare la logica nel
mailserver, attraverso opportune configurazioni, eventualmente
aggiungendo sul DB di appoggio nuove tabelle o campi per gestire tali
configurazioni e le query connesse.
Se facessi uso di funzionalità interne al DB, non ne avrei alcuna
necessità, dato che potrebbe essere il DB stesso a implementare tutta la
logica di cui il mailserver ha bisogno, permettendo anzi di implementare
logiche che magari il mailserver stesso (data la natura strutturata
degli accessi alla base dati) non sarebbe in grado di riprodurre, o di
riprodurre a costo di una elevata complessità.
Non ho idea di quanto questo possa impattare sulle prestazioni: non c'ho
mai provato, nè credo che avrò a breve necessità di farlo, dato che
l'uso che faccio di quelle query per ora non le richiede.
Se però mi chiedi se possono mai avere un senso, francamente rispondo
"sì, in alcune situazioni sarebbero molto utili"...
-- 
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.

 me. Rotfl.
Non sapevo che postfix avesse un supporto per LDAP.
E' grave?


 "sì, in alcune situazioni sarebbero molto utili"...
beh decidere una implementazione sui "sarebbe", "sarebbero" non mi 
convince troppo. Difatti in quel senso tu non lo stai sfruttando.


 mettere mani sopra per aggiungere record).
beh, chiaro, i programmatori SQL in giro sono sicuramente tanti.
dall'altra parte, con redhat DS, disponi di una GUI Java e di una 
interfaccia web proprietari (il vecchio Netscape DS aveva l'interfaccia 
web, quindi credo che redhat DS se la porti ancora dietro.
il problema piuttosto e' con OpenLDAP: non si possono gestire tutte le 
gerarchie di un tree ldap complessi dai file di testo. E non e' nemmeno 
pensabile di lavorare su file ldif.
Lo si puo' anche fare, ma non come lavoro di routine.


 2 mesi :)
Dipende dal turnover aziendale...
Può anche darsi che siano più le creazioni/cancellazioni delle mail 
rispetto agli accessi, ergo: persona assunta e licenziata dopo mezzora 
(non aveva ancora configurato il cliente)

 2 mesi :)
Vero.
Moltiplica questa prassi per alcune migliaia di domini, ciascuno con i
propri utenti e i propri amministratori con tutti "dentro_e_fuori"
operati dagli stessi, e hai la normale operatività di un service provider...
Non che LDAP non potrebbe andrebbe bene ugualmente, ma è giusto per
contestualizzare...


 E' grave?
No, figurati.



mi fai ricordare che ho lavorato per una azienda moooolto grande e che 
ogni tanto ci arrivavano le richieste di creazione di utenti. Ricordo che 
abbiamo fatto un conteggio degli utenti unix sulle nostre macchine e 
credo fosse circa 40mila (wow!). Ma anche in quel caso, la scrittura era 
sempre relativamente bassa.
Comunque, in questi casi, la scrittura avviene su un LDAP master, 
normalmente non accessibile per i lookup, e viene poi replicato sugli 
altri.... anche se la replica e' anch'essa un'operazione di scrittura :P
Detto tutto cio' mi viene in mente un'altra questione, credo di primaria 
importanza:
nel caso di una entita' business (che non sia un internet provider) dove 
la metti la rubrica condivisa?? Qui non hai scelta. E allora che fai 
installi SQL e LDAP?
p.s.: provate redhat DS, credo che inizierete a cambiare idea ;)


Il Mon, 09 Jul 2007 16:08:52 +0000, Max_Adamo ha scritto:
[cut]
mannaggia, scusa per il quoting.


 quello che deve fare Luca noi non lo sappiamo.
No, però ha scritto che "In lettura dobbiamo fare parecchie JOIN tra le
varie tabelle". Il che mi fa pensare a una struttura relazionale.
-- 
CdL

>>
-- 
CdL

 oracle) ne ha varie, come il case sensitive
Il mondo è Case Sensitive.
Solo l'Impero del Male è cASE inSEnSiTivE.
:)
-- 
CdL

 installi SQL e LDAP?
Come hai detto, in quel caso di fatto non c'è scelta, quindi mi pare
fuori luogo portare lo scenario, considerando quello di cui si parla.
E' come se ti dicessi: "nel caso di una entità business, dove metti i
dati del gestionale aziendale"?
Abbastanza inutile, come esempio, ti pare?
Tornando al quid, l'esempio che porti può comunque dare uno spunto
potenziale, che potremmo riformulare così:
Posta una realtà in cui esistono applicazioni nativamente basati su SQL
(come i gestionali) e applicativi strutturalmente basati su LDAP (come
le rubriche.
e
Posta la necessità di integrare entrambe le basi dati con le
funzionalità del mailserver.
allora:
Quale tra le due basi dati ha senso utilizzare per fungere da backend al
mailserver?
IMHO, quella che richiede il minor sforzo di integrazione con il resto.
Quindi, che si tratti di LDAP o SQL è funzionalmente indifferente, e
dipende dai fattori al contorno, più che dalla tipologia di base-dati in sè.


 metatifisiche, sicuramente non alfabetiche.
Queste mi sanno più pippate di Windows che di Oracle...
-- 
CdL

 
Io rispondo sia che mi chiami roberto, che Roberto.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 Io rispondo sia che mi chiami roberto, che Roberto.
Io no, i nomi propri vanno sempre con la lettera maiuscola.
In inglese, I != i
Se poi tutto il mondo sbaglia (ed è così, dato che tutti scrivono "i am" 
anzichè "I am") è un altro paio di maniche.

 In inglese, I != i
Io lo so, ma bisognerebbe che lo disimparassero anche in microsoft.
Ho avuto per un certo periodo una versione di office che si lasciava
convincere ad essere localizzata in italiano, ma non c'era verso di
fargli accettare l'articolo "i".
Ehi, le faccine le uso a periodi alterni, ma li' ci volevano.


 dallo strict matching, proprio per agevolare chi deve cercare dati.
Se il database è case sensitive e hai una business rule che dice che
"Roberto" e "roberto" sono la stessa identica cosa puoi sempre uscirne
fuori in qualche modo.
Viceversa, se il database è case insensitive e la tua business rule dice
che "Roberto" e "roberto" sono due dati diversi non c'è pezza di
farglielo capire.
-- 
CdL

 gerarchie di un tree ldap complessi dai file di testo.
Se il problema si riduce alla gestione del server via GUI, allora posso
dire che per OpenLDAP (ma penso che siano utilizzabili anche su altri
server) ve ne sono abbastanza, sia native che Java che web
Enrico
P.S. personalmente mi trovo bene con LDAP Browser

 Queste mi sanno più pippate di Windows che di Oracle...
??? tutti i prodotti installati sono forniti dalla oracle, e il problema è 
dovuto al supporto di una marea di 'lingue' e 'caratteri', ed è un problema
per niente trascurabile, ed è per niente facile farsi un'esperienza
adeguata.

 :)
Se come no, sono stati molto i clienti che, negli omnipresenti elenchi di
selezione nelle camionate di anagrafiche di un gestionale, devono
ricordarsi esattamente come hanno scritto le varie descrizioni e vari
codici altrimenti non trovano un tubo.
Si certo, il gestionale potrebbe o dovrebbe convertire tutto in un certo
case ma ....

 Mai toccato un parametro di configurazione di Oracle in vita mia
Si vede che sei o fortunato, o non fai il DBA Oracle
Enrico

 ma con meno attenzione alla compatibilità), 
Ah, il campo DATE che fa tutto...
Enrico

 Io lo so, ma bisognerebbe che lo disimparassero anche in microsoft.
In teoria l'hanno imparato (NTFS e` case sensitive), in pratica fanno
finta di non saperlo (explorer non tiene conto del case)
Enrico

 Si vede che sei o fortunato, o non fai il DBA Oracle
Cerco semplicemente di disegnare correttamente le basi dati e di
scrivere statement SQL il più possibile ottimizzati, il che nel 99% dei
casi rende del tutto inutile giocare coi parametri di configurazione,
credimi.
-- 
CdL

 adeguata.
Basta leggere la documentazione, c'è un volume appositamente dedicato
alla globalizzazione.
-- 
CdL

 tiene in linea 3 backup on line di giorni differenti.
Io ho risolto mettendo alla notte il db in read-only e facendo un export
dei db che voglio backuppare. Poi faccio un tar.gz del file di export e la
dimensione dei backup diventa ragionevolmente piccola.
Il sistema non è dei migliori, sono d'accordo. Ma in caso di sputtanamento
di un singolo schema, dropperei tutto e reimporterei dall'export. 
In caso di sputtanamento di oracle/hardware/ecc... provvederei allo
spianamento, reinstallazione e reimportazione degli schemi.
Sicuramente avrò tempi di down più lunghi, ma ho spazi più contenuti.

 Definisci "grosse mole di dati".
]zac[
Un po' meno di troppo.

 Sicuramente avrò tempi di down più lunghi, ma ho spazi più contenuti.
Si, giusto, fortunatamente nel mio caso ho spazio disponibile in abbondanza
sui dischi e dopo una passata di tar e gzip le dimensioni dei dati da
inserire nel backup calano vertiginosamente.

 Ah, il campo DATE che fa tutto...
]zac[
Magari ( :) ), più che altro applicazione multi database.

 Un po' meno di troppo.
Ma sempre piu' di abbastanza.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 credimi.
Non ti credo per un semplice motivo: nelle realta` in cui mi trovo,
capita spesso che debbano essere modificati dei parametri di
configurazione di Oracle per i motivi piu` disparati (aumento del numero
di job, esecuzione di applicazioni esterne...). Per questo dico che sei
fortunato o che non fai il DBA
Enrico

 
Un bel tot di piu'.


 Magari ( :) ), più che altro applicazione multi database.
Appunto, con un campo DATE che prende tutto il timestamp, ti aspetti un
comportamento simile anche su altri database (cosa che sistematicamente
non avviene)
Enrico

> ma LOL. Lavora a Dresda. haihaihai....
effetti dell'europa unita...
loro mandano giu' i wurstel, noi mandiamo su incompetenza... :)
-- 
Spolvera la mia email per rispondermi
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it