Gibt es einen Grund, extrem abgekürzte Tabellennamen zu verwenden?

Wir verwenden eine Datenbankkonfiguration aus einer Anwendung eines Anbieters, die die Namen von Datenbanktabellen nur sehr schwer lesen kann, und keine Dokumentation darüber, was wo gespeichert ist. Ich kann sehen, warum man die Tabellenstruktur in einer proprietären App verschleiern möchte, aber eines der Verkaufsargumente dieser Anwendung (Enterprise Resource Planning) war ihre Anpassbarkeit.

Tabellennamen sind wie aptrx (Accounts Payable Transactions) und apmaster_all (seltsamerweise ist dies die Lieferanten-Tabelle). Es ist eine äußerst komplexe Datenbank, daher habe ich mich gefragt, ob die Konvention logisch ist oder ob sie nur absichtlich oder auf andere Weise verschleiert wurde.

Meines Wissens wird die Länge des Tabellennamens die Leistung nicht merklich beeinflussen, richtig? Die Datenbank ist sehr komplex (Hunderte von Tabellen), daher macht das Sortieren Sinn, aber ich kann mir nicht vorstellen, warum AccountsPayableTransactions aptrx nicht vorzuziehen ist.

Oracle hat seit langem eine Beschränkung für Tabellennamen von 30 Zeichen. Ich vermute, dass dies ein Legacy-Problem ist, das auf einer ursprünglichen 16-Bit-Umgebung basiert.
Die Länge eines Tabellennamens kann sich geringfügig auf die Leistung auswirken, da alle Namen in einem Datenwörterbuch gespeichert und auch für Abfragen analysiert werden müssen, aber ich glaube nicht, dass Sie den Treffer messen können.

Ein wichtigerer Effekt von kurzen Tabellennamen ist, dass es schwierig ist, damit zu arbeiten. Auch ich muss ein Unternehmensdatenbankschema mit Kurznamen pflegen. Es gibt keinen guten Grund, kurze Tabellennamen zu haben. Einfache Wartung übertrifft jedes Mal die Verschleierung oder alte DOS-Gewohnheiten.

Ich denke, es gibt zwei Dinge, die noch gesagt oder ausgearbeitet werden müssen:

1. Dinge zu benennen ist nicht so trivial, wie es sich anhört

   In der Informatik gibt es nur zwei schwierige Probleme: die Ungültigmachung des Cache und die Benennung von Dingen. Phil Karlton

2. Während kurze sinnlose Namen immer schlecht sind, sind lange Namen nicht immer gut - unser Gehirn verfügt über einen eingebauten tl; dr Schwelle , die überraschend niedrig ist. 30 Zeichen sind normalerweise ausreichend, aber ich bevorzuge das RDBMS, um in Ausnahmefällen , in denen dies nicht der Fall ist, mehr zuzulassen (und genau wie in der Sprache sind längere Namen nützlicher für Dinge, über die wir nicht so oft sprechen - wie Einschränkungsnamen und Kürzere Namen sind nützlicher für Tabellen, die wir ständig abfragen.

Ich bin immer versucht, zu wenig Zeit mit der Auswahl von Namen zu verbringen, und bereue es später immer wieder - das Ändern von Namen kommt nur selten vor

Faulheit. Mit den Optionen von IntelliSense und Drittanbietern ist das Tippen eine wirklich schwierige Entschuldigung. Mir wäre es lieber, wenn die Namen aussagekräftige und lesbare Wörter hätten.

Tabellennamen sind wie aptrx (Accounts Payable Transactions) und apmaster_all (seltsamerweise ist dies die Lieferanten-Tabelle). Es ist eine äußerst komplexe Datenbank, daher habe ich mich gefragt, ob die Konvention logisch ist oder ob sie nur absichtlich oder auf andere Weise verschleiert wurde.

Bekannte Abkürzungen sind normalerweise der Rechtschreibung vorzuziehen. Wenn eine Abkürzung einigen Leuten gut bekannt ist, aber nicht genug, hören wir auf, sie als Abkürzung zu bezeichnen, und beginnen, sie als Code zu bezeichnen.

Abkürzungen sparen Platz auf Plattformen mit engen Grenzen, obwohl dies heute weniger wichtig ist als vor 30 Jahren. (Ich erinnere mich an die Arbeit an einem System in den 1980er Jahren, das Sie auf 6 oder 8 Zeichen für einen Tabellennamen beschränkt hat.)

Durch Abkürzungen werden Tabellennamen und Spaltennamen in der Regel besser lesbar, sofern die Abkürzung gut durchgeführt wird. Wenn ich den ganzen Tag am Code für AP gearbeitet habe, würde ich lieber Spaltennamen wie "ap_trx.inv_num" als "accounts_payable_transactions.invoice_number" lesen. (Ich mag Unterstriche.) Die Eingabe langer Namen ist mit einem guten Texteditor kein großes Problem.

In Abrechnungssystemen sind sowohl "ap" als auch "trx" bekannte Abkürzungen. Andere umfassen "ar", "gl" und "gj" für Debitorenbuchhaltung, Hauptbuch und allgemeines Journal.

Wenn ich in einem gut gestalteten System Kreditorenbuchhaltungstransaktionen in einer Tabelle mit dem Namen "aptrx" finden würde, würde ich hoffen, Debitorenbuchhaltungstransaktionen in artrx, Hauptbuchhaltungstransaktionen in gltrx und so weiter zu finden. Ich finde "apmaster_all" ein wenig rätselhaft, aber wenn ich auch "armaster_all" finde, würde ich annehmen, dass der erste alle Anbieter (im Gegensatz zu aktiven oder inaktiven Anbietern) und der zweite alle Kunden in ähnlicher Weise hielt.

In anderen Problembereichen finden Sie andere bekannte Abkürzungen. Bei der Adressierung finden Sie Abkürzungen wie "addr" für die Adresse, "st" für die Straße, "usps" für den United States Postal Service, "ups" für den United Parcel Service, "cty" für den Landkreis und "zip" für die Zonenverbesserung Code und so weiter.

Ich würde diese Verschleierung nicht nennen. Wenn Kreditorenbuchhaltungstransaktionen in einer Tabelle mit dem Namen "cdrs21" gespeichert würden, würde ich diese Verschleierung nennen. (Obwohl ich einmal für eine Firma gearbeitet habe, die alle ihre Mainframe-Assembler-Module so benannt hat. Zeichenbegrenzungen, keine Verschleierung.)

Aber nützliche Datenbanken wachsen, und Sie stoßen auf ein Problem, wenn Datenbanken groß werden. Wenn Sie Ihrer Datenbank Problemdomänen hinzufügen, stoßen Sie auf Situationen, in denen bekannte Abkürzungen kollidieren. Wenn Sie sich mit den Medien befassen, könnte "ap" auch "Associated Press", "Alternative Press" oder "Advance Placement" abkürzen. In diesem Fall müssen Sie entweder auf Abkürzungen verzichten oder zu Codes wechseln. Je größer die Organisation (und je größer die Datenbank), desto häufiger finde ich Codes.

Ich stimme nur zu "Mein Gott, die Schutzbrillen tun nichts für diese schreckliche Namenskonvention". Das Datenverwaltungsteam in meiner letzten Umgebung gab an, der Grund für die Verwendung von abgekürzten Tabellennamen sei eine DB2-Beschränkung (wir hatten DB2 unter z / os und SQL Server) von 18 Zeichen für Tabellen und Spalten. Ich habe umgehend darauf hingewiesen, dass dies mit der Dokumentation auf der IBM-Website nicht stimmt. Sie gaben dann an, es handele sich um ein COBOL-Problem (ja, sie wurden aktiv für COBOL entwickelt), falls es erforderlich sei, mit der Datenbank zu sprechen, die dann von den MF-Jockeys widerlegt wurde. Schließlich war ihre Antwort, dass es unser Veröffentlichungsstandard ist.

Wir haben beim Normungsausschuss eine Petition eingereicht, um die Länge von 18 auf 32 Zeichen zu erhöhen, und eine Beschränkung auf 30 Zeichen erhalten. Dies führte dazu, dass Tabellen von nutzlosen Namen von 'SR_M_DLY_ADV_PRD_S' zu 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML geändert wurden

Nach ungefähr einem Dutzend Jahren Erfahrung bieten verkürzte Tabellennamen keine greifbaren Vorteile und verursachen höhere Entwicklungs- und Wartungskosten, da ich immer auf Datenwörterbücher zurückgreifen muss, um den Bildschirmmüll in einen aussagekräftigen Bezeichner zu übersetzen. Dies steht im Gegensatz zu logisch benannten Entitäten, mit denen ich gearbeitet habe und die sich größtenteils aus dem Speicher wiederherstellen lassen, weil sie intuitiv benannt wurden.

Es ist eine Gewohnheit (ich stimme Kevinsky zu). Es handelte sich um eine Reaktion auf einige alte (möglicherweise vorhandene) Probleme hinsichtlich der Einschränkung (Namenslänge, Leerzeichen zwischen Wörtern komplexer Namen, mehrsprachig usw.) des Betriebssystems (z. B. DOS, Windows) und einiger Software, die diese Namen nicht handhabte. Erfahrene Leute sagten: "Tun Sie dies (verwenden Sie kurze und mit Unterstrichen getrennte Namen) und alles wäre in Ordnung."

Aus den oben genannten Gründen benenne ich Plakate gerne beschreibend.

Es gibt aber noch einen weiteren Vorteil. Mit der beschreibenden Benennung können Sie beispielsweise verschachtelte Namen verwenden. Angenommen, Sie haben einen Tisch namens Employee. Wenn Sie eine Beziehung zu einer anderen Tabelle haben, könnte diese EmployeeAddress heißen. Oder Mitarbeiterabteilung. Mit der kryptischen Kurzbezeichnung ist dies fast unmöglich.

Hängt davon ab, wie komplex die zugrunde liegenden Definitionen jeder Spalte sind. Ich denke, die Leute werden mit der Verwaltung von Metadaten faul, wenn sie solche sehr beschreibenden Spaltennamen sehen, und sie sind sogar unvollständige Beschreibungen. Sie können auch fragen, warum etwas abgekürzt wird.