[database] differenza fra embedded and server

[MEMon]

Qual'è la differenza fra i due tipi di database? Quando scegliere uno e quando l'altro?

Da quel che ho capito l'embedded viene "installato" insieme all'applicazione che ne fa uso, non necessita quindi di un servizio o applicazione a parte per girare.
Immagino quindi che installando la stessa applicazione che contiene un db embedded si creano due diversi database, giusto?

Uno server invece ha il suo bel srevizio o applicazione con il quale si avvia e ci si possono connettere diversi programmi. Quindi il database può venire condiviso da più applicazioni, dico bene?

Considerando che a me serve avere diverse applicazioni che fan uso dello stesso database, a me serve un db server giusto?

[PGI-Bis]

E' una mera questione di processi. L'embedded viene eseguito nello stesso processo del programma che lo usa, il non embedded ha un processo a parte.

Quanto alla questione "server", se intendiamo il termine nel senso di programma che offre una qualche funzionalità a programmi eseguiti in processi diversi dal proprio, l'embedded può essere o non essere server mentre il non embedded lo è sempre (di necessità, altrimenti non servirebbe a nulla).

[MEMon]

Facciamo che devo realizzare un pacchetto che comprende tra applicazioni, che fan uso dello stesso database ma hanno funzionalità diverse e sono quindi dedicate a utenti diversi, in questo caso qual'è la modalità che fa per me?

[PGI-Bis]

Quella che ritieni essere la migliore sulla base di una scelta tecnicamente motivata .

[MEMon]

Originariamente inviato da PGI-Bis

Quella che ritieni essere la migliore sulla base di una scelta tecnicamente motivata .

eh beh, questa si che è una risposta!

[cdimauro]

Se le applicazioni devono accedere contemporaneamente allo stesso database, meglio far uso di un apposito server.

Ti suggerirei di usare FireBird: può funzionare indifferentemente come engine SQL embedded o come server, e puoi passare dall'uno all'altro senza alcuna difficoltà.

Magari all'inizio puoi sviluppare le tue applicazioni usandolo come embedded, e quando finisci il tuo progetto cambi la riga di codice per il login al database, e passi a usarlo in configurazione server.

[MEMon]

Originariamente inviato da cdimauro

Se le applicazioni devono accedere contemporaneamente allo stesso database, meglio far uso di un apposito server.

Ti suggerirei di usare FireBird: può funzionare indifferentemente come engine SQL embedded o come server, e puoi passare dall'uno all'altro senza alcuna difficoltà.

Magari all'inizio puoi sviluppare le tue applicazioni usandolo come embedded, e quando finisci il tuo progetto cambi la riga di codice per il login al database, e passi a usarlo in configurazione server.

Si infatti sto guardando per capire come funziona questo db.

Te con cosa lo gestisci? Ho scaricato per FlameRobin... non mi sembra sto gran chè... mi piacerebbe qualcosa che mettesse a disposizione una bella interfaccia grafica per creare tabelle e colonne, tipo phpmyadmin oppure mysql query browser.

Comunque una cosa che non capisco, ho creato un utente, il classico root - root, vorrei cancellare l'utente amministratore sysdba già esistente, ma è possibile? In pratica vorrei avere un unico utente con tutti i diritti.

[cdimauro]

Originariamente inviato da MEMon

Si infatti sto guardando per capire come funziona questo db.

Te con cosa lo gestisci? Ho scaricato per FlameRobin... non mi sembra sto gran chè... mi piacerebbe qualcosa che mettesse a disposizione una bella interfaccia grafica per creare tabelle e colonne, tipo phpmyadmin oppure mysql query browser.

Uso principalmente ISQL, il tool da command line, perché DB e tabelle li creo con uno script SQL che scrivo a mano e che me li descrive.

Come interfaccia dotata di GUI utilizzo IBOConsole, ma solo per eseguire query.

EDIT: dimenticavo. Adesso c'è pure questo che promette molto bene.

Comunque una cosa che non capisco, ho creato un utente, il classico root - root, vorrei cancellare l'utente amministratore sysdba già esistente, ma è possibile? In pratica vorrei avere un unico utente con tutti i diritti.

Personalmente non ho mai creato l'utente root, proprio perché c'è già SYSDBA di default che ha questo ruolo.

[MEMon]

Originariamente inviato da cdimauro

Personalmente non ho mai creato l'utente root, proprio perché c'è già SYSDBA di default che ha questo ruolo.

Ma se uno vuole personalizzare l'utente amministratore quindi non può?

[cdimauro]

Sì, puoi crearne anche un altro con un altro nome e con gli stessi privilegi, e cancellare SYSDBA (non so se è possibile una semplice rinomina, che dovrebbe risolvere subito il problema).

[MEMon]

Originariamente inviato da cdimauro

Sì, puoi crearne anche un altro con un altro nome e con gli stessi privilegi, e cancellare SYSDBA (non so se è possibile una semplice rinomina, che dovrebbe risolvere subito il problema).

Si infatti ho fatto così. Sto provando a creare tabelle, ma per caso auto_increment non è supportato, dico bene?

Non è che me lo devo simulare con un trigger?

[cdimauro]

Sì sì. Devi creare un generatore (o sequence, che è il termine che usa nello standard SQL) e usarlo all'intero di un trigger BEFORE INSERT.

E fidati: QUESTA è la strada maestra per evitare inutile lock a un'intera tabella. Modello abominevole e, purtroppo, piuttosto comune.

[MEMon]

Originariamente inviato da cdimauro

Sì sì. Devi creare un generatore (o sequence, che è il termine che usa nello standard SQL) e usarlo all'intero di un trigger BEFORE INSERT.

E fidati: QUESTA è la strada maestra per evitare inutile lock a un'intera tabella. Modello abominevole e, purtroppo, piuttosto comune.

Va bene, io ormai ero abituato ad auto_increment ma vedo che molti db non lo usano, è una specifica solo di mysql?

Normalmente per ogni tabella una chiave primaria auto increment ce la metto(mettevo?), se dovessi creare un trigger ogni volta non diventerebbe tutto meno efficiente?

[cdimauro]

Originariamente inviato da MEMon

Va bene, io ormai ero abituato ad auto_increment ma vedo che molti db non lo usano, è una specifica solo di mysql?

Purtroppo no: ce ne sono altri.

Normalmente per ogni tabella una chiave primaria auto increment ce la metto(mettevo?),

Sì, mettila.

se dovessi creare un trigger ogni volta non diventerebbe tutto meno efficiente?

Non vedo perché. Anzi, se ci sono parecchie transazioni concorrenti, si verifica l'esatto opposto: non avendo lock sull'intera tabella, il sistema è più veloce / efficiente.

[MEMon]

Originariamente inviato da cdimauro

Purtroppo no: ce ne sono altri.

Sì, mettila.

Non vedo perché. Anzi, se ci sono parecchie transazioni concorrenti, si verifica l'esatto opposto: non avendo lock sull'intera tabella, il sistema è più veloce / efficiente.

Perfetto allora, non lo sapevo, grazie mille.