Relazione tra istanza di catalogo, schema, utente e database

Per confrontare database di diversi fornitori (Oracle, SQL Server, DB2, MySQL e PostgreSQL) come posso identificare un object in modo univoco e ho bisogno di un catalogo? Ad esempio, nel DatabaseMetadata di Java dovrei specificare almeno il catalogo e lo schema fooPattern.

È vero che il catalogo è solo un’astrazione di archiviazione dei dati?

In Oracle:

  • istanza del server == database == catalog == tutti i dati gestiti dallo stesso motore di esecuzione
  • schema == spazio dei nomi all’interno del database, identico all’account utente
  • utente == proprietario dello schema == account con nome, identico allo schema, che può connettersi al database, proprietario dello schema e utilizzare oggetti possibilmente in altri schemi
  • per identificare qualsiasi object nel server in esecuzione, è necessario (nome schema + nome object)

In PostgreSQL:

  • istanza del server == db cluster == tutti i dati gestiti dallo stesso motore di esecuzione
  • database == catalog == singolo database all’interno del cluster db, isolato da altri database nello stesso cluster db
  • schema == spazio dei nomi all’interno del database
  • utente == account denominato, che può connettersi al database, possedere e utilizzare gli oggetti in ciascun database consentito separatamente
  • per identificare qualsiasi object nel server in esecuzione, è necessario (nome del database + nome dello schema + nome dell’object)

In MySQL:

  • istanza del server == non identificata con il catalogo, solo un insieme di database
  • database == schema == catalog == uno spazio dei nomi all’interno del server.
  • utente == account con nome, che può connettersi al server e utilizzare (ma non possedere – nessun concetto di proprietà) oggetti in uno o più database
  • per identificare qualsiasi object nel server in esecuzione, è necessario (nome del database + nome dell’object)

In Microsoft SQL Server:

  • istanza del server == set di database gestiti
  • database == namespace qualificatore all’interno del server, raramente indicato come catalogo
  • schema == owner == spazio dei nomi all’interno del database, legato ai ruoli del database, per impostazione predefinita viene utilizzato solo dbo
  • utente == account con nome, che può connettersi al server e utilizzare (ma non può possedere – lo schema funziona come proprietario) oggetti in uno o più database
  • per identificare qualsiasi object nel server in esecuzione, è necessario (nome del database + proprietario + nome dell’object)

Quindi penso che la risposta alle tue domande sia:

  1. Dipende dall’implementazione, se il nome del catalogo è necessario per identificare gli oggetti. Il significato di “catalogo”, “schema” e “database” varia da un’implementazione all’altra.

  2. Sì, un catalogo è un’astrazione di archiviazione dei dati. Penso che dovrebbe essere definito anche come spazio dei nomi isolato autonomo, ma non tutti i motori SQL lo fanno.

  3. Database e schema sono abbastanza ben definiti da tutti i fornitori. Il catalogo è talvolta sinonimo di “database” (almeno in Oracle e Postgres), a volte anche “schema” e talvolta anche in entrambi. Il termine catalogo spesso significa anche raccolta di metadati (ovvero tabelle di sistema).

Per DB2, lo schema viene utilizzato come spazio dei nomi. Quindi, se si desidera identificare univocamente un object in un database, si direbbe * schema.object_name *. Questo è un modo molto pratico per ottenere la multi-tenancy. È ansible avere uno schema separato per ciascun titolare nel database. Ciò fornisce una buona separazione delle preoccupazioni sia dalla sicurezza che dagli aspetti gestionali. È ansible avere schemi 32K in un singolo database DB2.

Un catalogo in DB2 è semplicemente una raccolta di tabelle di sistema che contengono metadati relativi al database. In generale, è considerata una ctriggers pratica accedere direttamente agli oggetti del catalogo. È preferibile utilizzare le funzionalità fornite dalla propria API (ad es. JDBC) per esplorare il catalogo e i metadati che contiene.

DB2 ha anche altri livelli di astrazione. È ansible avere più istanze di DB2 in esecuzione sulla stessa macchina. Ogni istanza può gestire 256 database separati (ciascuno con schemi 32K). Il numero di istanze DB2 su un server è limitato solo dalla quantità di memoria disponibile. Ad un certo punto abbiamo avuto 120 istanze di DB2 (ognuna con un database e 10 connessioni) in esecuzione su Amazon EC2 m1.large. È inoltre ansible avere più installazioni di DB2 su un singolo server. è utile quando si prova una nuova versione alla quale si intende eseguire la migrazione. Lo trovo confuso anche se spesso dimentico di passare all’installazione giusta.

Ciò che è menzionato qui su mysql in post di filiprem sembra essere errato. Come per i seguenti collegamenti, in mysql il catalogo jdbc corrisponde al database. Lo schema jdbc non è supportato.