Unterstriche oder camelCase in PostgreSQL-Bezeichnern, wenn die Programmiersprache camelCase verwendet?

Question

Jun 30, 2012, 03:27 AM

postgresql camelcasing naming-conventions database-design oop

Unterstriche oder camelCase in PostgreSQL-Bezeichnern, wenn die Programmiersprache camelCase verwendet?

Das hat mich eine Weile gestört und ich kann nicht zu einer Lösung kommen, die sich anfühltRecht...

Eine OO-Sprache vorausgesetzt, in der die übliche Namenskonvention für Objekteigenschaften camelCased lautet, und ein Beispielobjekt wie das folgende:

{
    id: 667,
    firstName: "Vladimir",
    lastName: "Horowitz",
    canPlayPiano: true
}

Wie soll ich diese Struktur in einer PostgreSQL-Tabelle modellieren?

Es gibt drei Hauptoptionen:

nicht zitierte Spaltennamen von camelCaseSpaltennamen von camelCase in AnführungszeichenNamen ohne Anführungszeichen (in Kleinbuchstaben) mit Unterstrichen

Sie haben jeweils ihre Nachteile:

Nicht zitierte Bezeichner werden automatisch in Kleinbuchstaben umgewandelt. Dies bedeutet, dass Sie eine Tabelle mit einem erstellen könnencanPlayPiano Spalte, aber der gemischte Fall erreicht nie die Datenbank. Wenn Sie die Tabelle überprüfen, wird die Spalte immer als angezeigtcanplaypiano - in psql, pgadmin, erkläre Ergebnisse, Fehlermeldungen, alles.

Zitierte Bezeichner behalten ihre Gültigkeit, aber sobald Sie sie so erstellen, werden Sie es tunimmer müssen sie zitieren. IOW, wenn Sie eine Tabelle mit einem erstellen"canPlayPiano" Spalte, aSELECT canPlayPiano ... wird versagen. Dies fügt allen SQL-Anweisungen unnötiges Rauschen hinzu.

Namen in Kleinbuchstaben mit Unterstrichen sind eindeutig, lassen sich jedoch nicht gut den Namen zuordnen, die von der Anwendungssprache verwendet werden. Sie müssen daran denken, unterschiedliche Namen für die Speicherung zu verwenden (can_play_piano) und für Code (canPlayPiano). Es verhindert auch bestimmte Arten der Code-Automatisierung, bei denen Eigenschaften und DB-Spalten gleich benannt werden müssen.

Also bin ich zwischen einem Felsen und einem harten Ort gefangen (und einem großen Stein; es gibt drei Möglichkeiten). Was auch immer ich tue, ein Teil wird sich unangenehm anfühlen. In den letzten 10 Jahren habe ich Option 3 verwendet, aber ich hoffe weiterhin, dass es eine bessere Lösung gibt.

Für Ratschläge bin ich dankbar.

PS: Mir ist klar, woher der Fall Folding und die Notwendigkeit von Zitaten kommt - der SQL-Standard oder vielmehr die Anpassung des Standards durch PostgreSQL. Ich weiß, wie es geht; Ich bin mehr an Ratschlägen zu Best Practices interessiert als an Erklärungen, wie PG mit Bezeichnern umgeht.