it-swarm.com.de

Ist das Hinzufügen des Präfixes "tbl" zu Tabellennamen wirklich ein Problem?

Ich schaue mir einige Videos von Brent Ozar an ( wie zum Beispiel dieses ) und er schlägt vor, Tabellen nicht mit ‘tbl’ Oder ‘TBL’ Vorzustellen.

Im Internet habe ich einige Blogs gefunden, in denen es heißt, dass es der Dokumentation nichts hinzufügt und dass „das Lesen länger dauert“.

Fragen und Überlegungen

  • Ist das wirklich ein Problem? Weil ich Tabellen seit meinem ersten dba-Job 'tbl' voranstelle (der leitende DBA hat mir gesagt, dass ich das für die Organisation tun soll ).
  • Muss ich das loswerden? Ich habe einige Tests durchgeführt, eine wirklich große Tabelle kopiert und ihr das Präfix 'tbl' gegeben, während ich sie behalten habe der andere ohne, und ich bemerkte kein Leistungsproblem.
94
Racer SQL

Ich hatte einmal einen Tisch und er war glänzend und schön. Es hielt alle Finanztransaktionen für eine Organisation. Und dann haben wir angefangen, Daten hinein zu laden.

Im aktuellen Monat können sie Werte so oft angeben und anpassen, wie sie möchten. In den letzten 10 Tagen eines Monats haben sie die Zahlen angepasst -> die ETL-Verarbeitung ausgeführt -> die Berichte mehrmals täglich überprüft. Sobald der Monat abgeschlossen ist, werden die Bücher versiegelt und können keine Werte mehr ändern.

Es ist erstaunlich, wie viele Finanzdaten ein Finanzdienstleistungsunternehmen generiert ... Etwas, das wir mit unserem Testdatensatz nicht erkannt haben, war, dass das Datenvolumen die Verfahren zum Monatsende unhaltbar machen würde. Das Löschen der "Daten des aktuellen Monats" dauerte immer länger, bevor sie durch den neuen Testlauf ersetzt wurden.

Wir mussten etwas tun, um die Verarbeitung zu beschleunigen, ohne die nicht katalogisierte Liste "Wer weiß was" zu beschädigen, die alle von der MonthlyAllocation-Tabelle abhängt. Ich beschloss, Zauberer zu spielen und die Tischdecke unter ihnen hervorzupeitschen. Ich bin auf die alte Schule gegangen und habe eine Partitioned View verwendet. Die Daten hatten bereits ein IsComplete-Flag, daher habe ich zwei Tabellen erstellt - jede mit entgegengesetzten Überprüfungsbeschränkungen: MonthlyAllocationComplete, MonthlyAllocationInComplete

Ich habe dann die partitionierte Ansicht mit demselben Namen wie die ursprüngliche Tabelle erstellt: MonthlyAllocation. Kein Prozess war klüger in Bezug auf die physische Änderung, die wir an der Datenbank vorgenommen haben. Es wurden keine Berichte veröffentlicht, keiner der Analysten mit direktem Zugriff meldete vorher oder nachher Probleme mit dieser "Tabelle".

Coole Geschichte, Bruder, aber wohin gehst du?

Was wäre, wenn sie dort eine Namenskonvention hätten, tbl_MonthlyAllocation? Was jetzt? Verbringen wir viele Arbeitsstunden damit, jede ETL, jeden Bericht, jede Ad-hoc-Tabelle in der Organisation zu durchlaufen und sie zu aktualisieren, um vw_MonthlyAllocation zu verwenden? Und dann gehen natürlich all diese Änderungen durch das Change Board und das ist immer ein schneller und schmerzloser Prozess.

Ihr Chef könnte fragen: Was ist die Belohnung für das Unternehmen für all diese Arbeit wieder?

Die andere Option ist, dass wir diese Ansicht mit dem Namen tbl_ belassen und nicht die ganze Zeit damit verbringen, Code zu testen, zu aktualisieren und bereitzustellen. Dies wird zu einer amüsanten Anekdote, die Sie allen neuen Mitarbeitern und solchen mit kurzen Aufmerksamkeitsspannen erklären, die mit der Datenbank arbeiten müssen, um festzustellen, warum Sie mit der Benennung von Objekten nicht übereinstimmen

Oder Sie codieren Objekte mit redundanten Metadaten nicht doppelt. Die Datenbank sagt Ihnen gerne, was eine Tabelle ist, was eine Ansicht ist, was eine Tabellenwertfunktion ist usw.

Namenskonventionen sind gut, malen Sie sich einfach nicht mit ihnen in eine Ecke.

215
billinkc

Brent hier (der Typ, auf den Sie sich in der Frage beziehen).

Der Grund, warum ich Ihnen sage, dass Sie tbl nicht vor Ihren Tabellennamen einfügen sollen, ist der gleiche Grund, warum ich sagen würde, dass Sie kein Kind vor den Namen Ihres Kindes einfügen sollen. Sie nennen sie nicht childJohn und childJane. Dies bringt nicht nur keinen Mehrwert, sie sind möglicherweise später kein Kind mehr - und Ihre Objekte werden möglicherweise später zu Ansichten.

133
Brent Ozar

Dies ist ein sehr subjektives Argument, aber hier ist meine Meinung: Das tbl-Präfix ist nutzlos.

Wie viele Szenarien betrachten Sie Code und Sie können nicht sagen, ob etwas eine Tabelle oder etwas anderes ist?

Welchen Wert fügt tbl hinzu, außer dass Sie beim Betrachten einer Liste von Tabellen im Objekt-Explorer mehr Arbeit leisten müssen, um die gesuchten Tabellen zu finden?

Einige Leute sagen, sie möchten, dass es in ihrem Code klar ist, wenn sie sich mit einer Tabelle oder einer Ansicht befassen. Warum? Und wenn dies wichtig ist, warum nicht einfach Ansichten auf besondere Weise benennen? In den meisten Fällen verhalten sie sich wie Tabellen, daher sehe ich wenig Wert in der Unterscheidung.

118
Aaron Bertrand

Es ist eine schreckliche Praxis.

tbl
tbl_
Table_
t_

... sie alle in der Produktion gesehen.

Eines der Produkte, mit denen ich gerade arbeite, hat die Hälfte der Tabellen mit dem Namen tbl_whatever Und die andere Hälfte mit dem Namen "normal" - sie haben offensichtlich Entwickler, die nach unterschiedlichen Standards arbeiten. Eine andere ihrer schlechten Gewohnheiten besteht darin, Spaltennamen, die Fremdschlüssel sind, fk voranzustellen, gefolgt vom Tabellennamen fk und dann dem Spaltennamen, wobei so schreckliche Spaltennamen wie fktbl_AlarmsfkAlarmsID. Diese Namenskonvention ist nur eine logische Erweiterung des gesamten tbl_% - Mantras, und Sie können sehen, wie lächerlich es wird!

Fast hätte ich die andere Datenbank vergessen, die mich täglich zum Weinen bringt. Datentypen, denen Spaltennamen vorangestellt werden ... dtPaymentDate, da der Name wirklich das Präfix dt benötigt? `

42
Philᵀᴹ

hören Sie nicht zu, wie Sie sich an andere Personen anpassen. proYou auxSollt immer empfehlen, nouPrefixes prepWith proYour adjTable nouNames. proI auxHave advEven verStarted gerUsing proThem prepIn adjNormal nouWriting.

comSee advHow adjEffective proIt verIs? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

25
ErikE

Die Verwendung eines solchen Präfixes ist als ngarische Notation bekannt. Die Prämisse ist einfach: Sie können anhand des Namens bestimmen, was etwas ist. Dies ist besonders häufig in Programmiersprachen der Fall, insbesondere wenn Entwickler monolithische Funktionen schreiben, die Dutzende von Seiten umfassen, entweder aufgrund mangelnder Kenntnisse oder mangelnder Sprachfunktionen. Es ist eine Gedächtnisstütze, mit der Entwickler Datentypen gerade halten können.

Im Allgemeinen wird diese Art der Benennung wahrscheinlich in wirklich altem Code oder von Entwicklern verwendet, die entweder nur lernen (und zufällig diese Gewohnheit gelernt haben) oder dies getan haben, solange sie sich erinnern können. Nach meiner Erfahrung ist es relativ selten, dass die ungarische Notation bei unerfahrenen Entwicklern spontan auftaucht, wenn sie nicht durch einen Programmierkurs oder ein Tutorial in die Notation eingeführt werden. Es ist wahrscheinlicher, dass sie Variablennamen wie i oder x oder verwenden acct .

Abgesehen davon, dass Sie sich in eine Ecke malen, ist dies wirklich nur Füllstoff. Die SQL-Syntax ist so präzise, ​​dass ein Entwickler immer wissen sollte, ob es sich um ein Feld, einen Datensatz oder einen Datensatz handelt (z. B. eine Tabelle, eine Ansicht usw.). Diese Syntax ist zwar eine gute Lehrhilfe, sollte jedoch in Produktionsdatenbanken normalerweise nicht vorhanden sein. Dies kann die Lesbarkeit beeinträchtigen und das Auffinden der gesuchten Tabelle erschweren, insbesondere wenn mehrere alternative Benennungsthemen wie tbl vs. . tabelle vs. tab usw.

Der Datenbank ist es egal , wie Sie Ihre Tabellen, Felder usw. aufrufen. Es handelt sich nur um Datenbytes, die in einer bestimmten Reihenfolge von angeordnet sind ihre menschlichen Operatoren oder Skripte. Die Menschen, die diese Daten pflegen müssen, werden jedoch aussagekräftige Namen wie "Benutzer", "Bestellung" und "Konto" zu schätzen wissen. Es ist auch praktischer, wenn Sie SQL-Abfragen verwenden, z. B. "Tabelle wie 'a%' anzeigen". Die Verwendung von Präfixen und Suffixen kann die ansonsten triviale Wartung unnötig erschweren.

21
phyrfox

Ich habe einige Blog-Beiträge wie this oder this (es gibt einige) gelesen, nachdem ich meine erste SQL Server-Instanz geerbt und festgestellt habe, dass viele Objekte vorangestellt wurden Entwickeln Sie neue mit einem weniger ausführlichen Ansatz und einer singulären Namenskonvention (viel einfacher für mich [ und möglicherweise andere Entwickler ], die an der objektrelationalen Zuordnung arbeiten).

Eines der am häufigsten verwendeten Präfixe war Tbl oder tbl, aber dann hatte ich TBL und tbl_ und selbst *TableName*_Tbl

(enter image description here

Wenn ich versuche, in Visual Studio abzufragen und zu arbeiten, ist dies nur die Hölle. Es wäre mir egal, wenn ein ganzer Satz von Tabellen mit dem Präfix tbl versehen wäre, aber bitte behalten Sie dies zumindest für die gesamte Datenbank bei.

Am Ende würde ich definitiv sagen, dass dies eine Frage der persönlichen Präferenz ist, aber es hat auch viel mit Beständigkeit zu tun, und wenn Sie diesen Weg gehen, werden viele Menschen glücklich sein, zumindest dass Sie es während Ihrer Entwicklung gleich halten.

... Auf der anderen Seite wollte ich nur sagen, wenn Sie einen anderen Ansatz wählen und sich für eine Tabelle mit Singularnamen ohne Präfix entscheiden, werden Sie einen Entwickler in Zukunft glücklich machen, und was ist wichtiger als Glück?

12
Nelz

Ja, das Hinzufügen eines Präfixes, das den Typ des Objekts angibt, ist ein Problem und nicht erforderlich . Weil,

  1. Manchmal beginnen Objekte das Leben als etwas, werden aber werden am Ende etwas anderes . (zB Tabelle tblXxx wurde aus irgendeinem Grund in tblXxxY und tblXxxZ aufgeteilt und durch eine Ansicht ersetzt, die die beiden neuen Tabellen verbindet. Jetzt haben Sie eine Ansicht mit dem Namen tblXxx).
  2. Wenn Sie im Editor tbl eingeben, bleibt die Funktion zur automatischen Vervollständigung 45 Sekunden lang hängen und zeigt Ihnen dann eine Liste mit 4000 Einträgen an.

Aber...

Ich werde Devil's Advocate spielen und etwas sagen, von dem andere geradezu abgeraten haben. Es gibt einige selten Fälle, in denen ein Suffix/Präfix nützlich sein könnte, und hier ist ein Beispiel aus der Organisation, für die ich arbeite.

Wir haben ein entitätsbasiertes ERP System, in dem die Geschäftslogik in Oracle PL/SQL geschrieben ist. Es ist fast zwei Jahrzehnte alt und dennoch ein sehr stabiles System (dies ist kein Legacy-System. Wir sind es) kontinuierlich weiterentwickeln).

Das System ist entitätsbasiert, und jede Entität ordnet eine Tabelle, mehrere Ansichten, mehrere PL/SQL-Pakete und einen Host anderer Datenbankobjekte zu.

Nun möchten wir, dass die Objekte, die zu derselben Entität gehören, denselben Namen haben, aber dennoch von Zweck und Typ unterscheidbar sind. Wenn wir also zwei Entitäten haben, die CustomerOrder und CustomerInvoice heißen, haben wir folgende Objekte:

  1. Tabellen zum Speichern von Daten [TAB Suffix]:
    • CUSTOMER_ORDER_TAB
    • CUSTOMER_INVOICE_TAB.
  2. Ansichten, die von Clients verwendet werden [Kein Suffix]:
    • CUSTOMER_ORDER
    • CUSTOMER_INVOICE.
  3. Schnittstelle für Grundoperationen; (PL/SQL-Pakete) [API Suffix]:
    • CUSTOMER_ORDER_API
    • CUSTOMER_INVOICE_API.
  4. Berichtsgeneratoren; (PL/SQL-Pakete) [RPI Suffix]:
    • CUSTOMER_ORDER_RPI
    • CUSTOMER_INVOICE_RPI.
  5. Indizes für Primärschlüssel [PK Suffix]:
    • CUSTOMER_ORDER_PK
    • CUSTOMER_INVOICE_PK.
  6. Sekundärindizes [IX Suffix]:
    • CUSTOMER_ORDER_XXX_IX
    • CUSTOMER_INVOICE_XXX_IX (Wobei XXX die Verwendung des Index beschreibt).
  7. ... und so weiter.

Dies ist in der Tat eine Form von Apps Ungarisch (beachten Sie, dass derselbe Typ von Objekten je nach Zweck unterschiedliche Suffixe haben kann). Aber mit einem Suffix anstelle eines Präfixes. Ich kann Ihnen nicht genug sagen, wie einfach dieses System zu lesen ist. IntelliSense funktioniert tatsächlich, weil ich anstatt TBL einzugeben und 4000 Ergebnisse zu erhalten, Customer eingeben und alle Objekte abrufen kann, die zu Entitäten mit dem Namen Customer* Gehören.

Hier habe ich Ihnen gezeigt, wie nützlich Metadaten können sind. Der Zweck besteht darin, einen verwandten Satz von Datenbankobjekten zu haben, die durch einen einzelnen Namen identifizierbar sind, sie jedoch anhand ihres Zwecks zu unterscheiden.

Allerdings , wenn Sie nicht über diese Art von System verfügen, können Sie weder den Typ Des Objekts voranstellen noch mit einem Suffix versehen.

Beachten Sie, dass wir keine Suffixe wie _table, _package Oder _view Verwendet haben (d. H. Den Typ des Objekts). Beispielsweise sind sowohl (3) als auch (4) PL/SQL-Pakete, verwenden jedoch ein anderes Suffix. Dies gilt auch für (5) und (6), die beide Indizes sind. Das Suffix basiert also eher auf Zweck als auf dem Typ.

11
sampathsris

tl; dr Es fügt (sehr wahrscheinlich) redundante Informationen hinzu, was zu kognitivem Overhead führt, und sollte daher entfernt werden.

Kontext ist eine wunderbare Sache, besonders in Computersystemen. Außerhalb des Kontexts konnte man unmöglich sagen, ob etwas mit dem Namen users eine Tabelle, eine Ansicht, eine gespeicherte Prozedur oder etwas ganz anderes ist. Ältere (oder nur schlecht geschriebene) Systeme und Sprachen machen es oft schwierig, den Kontext beim Lesen des Codes zu ermitteln. In Bash können Sie beispielsweise nicht sagen, was function users Macht, ohne mindestens den Inhalt der Funktion zu lesen. In Java ist Map<Uid,UserDetails> users() ziemlich transparent, und Sie können leicht bis ins Detail gehen.

Wenn Sie dieses Argument auf SQL-Tabellen übertragen , wann wäre es für die Benutzer von users nützlich zu wissen, ob es sich um eine Tabelle oder eine Ansicht handelt? Mit anderen Worten, ist ein tbl Präfix, das jedem Verbraucher etwas sagt, was er nicht weiß und benötigt zu wissen? Hoffentlich schreibt die überwiegende Mehrheit der Verbraucher DML- und DQL-Abfragen dagegen. Für sie sollte es nur eine andere Datenquelle sein, und ob es sich um eine Ansicht oder eine Tabelle handelt, sollte genauso relevant sein wie ob sie partitioniert, auf einer Festplatte oder SSD gespeichert oder ein anderes technisches Detail ist. Der DBA muss diese Details natürlich kennen, um einige seltene DDL/DCL-Abfragen ausführen zu können, aber es scheint kontraproduktiv, den Namespace für die Minderheit zu verschmutzen, die wirklich weiß, wie man im Schema navigiert und alle technischen Details abruft.

10
l0b0

Eines der Merkmale eines relationalen Datenbankverwaltungssystems besteht darin, dass es die logische Darstellung von Informationen für Clients vom physischen Speicher trennt. Ersteres sind Spalten in einem Rowset. Letzteres ist als Dateien auf einem Speichervolumen. Es ist die Aufgabe des DBMS, einander zuzuordnen. Es ist nur für den DBA oder den Systemadministrator von Belang, welche Hardware den Informationsbedarf unterstützt. Der Verbraucher muss und sollte sich dieser Bedenken nicht bewusst sein.

Der Client sollte sich auch keine Gedanken darüber machen, wie ein Rowset aufgebaut ist. Eine Basistabelle, eine Ansicht oder eine Funktion sind in dieser Hinsicht alle identisch. Jedes erzeugt einfach eine Reihe von Zeilen und Spalten, die der Client verwendet. Selbst ein einfacher Skalar kann als einzeilige, einspaltige Tabelle betrachtet werden. Das Zeilen-/Spaltenmodell ist der Vertrag zwischen dem Client und dem Server.

Durch das Präfixieren der Namen der Artefakte mit ihrem Implementierungstyp wird diese Trennung von Bedenken aufgehoben. Der Client kennt jetzt die Interna des Servers und ist von diesen abhängig. Eine Änderung der Servercodierung erfordert möglicherweise eine Überarbeitung des Clients.

9
Michael Green

Es gibt hier viele Antworten, denen ich zustimme und die Ihnen sagen, dass dies keine sehr wertvolle Namenskonvention ist. Für diejenigen, die von den anderen Antworten nicht überzeugt sind, werde ich versuchen zu demonstrieren, was viele andere Antworten sagen.


SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

In der obigen Anweisung wähle ich drei Spalten aus etwas mit dem Namen dbo.foo. Eine der Hauptbeschwerden der Präfixer ist, dass sie nicht wissen, ob dbo.foo ist eine Tabelle oder eine Ansicht. Das ist natürlich eine der Stärken einer Sichtweise als Abstraktion, aber ich schweife ab. Sie sagen, wir sollten das Objekt wie folgt voranstellen dbo.tblFoo. Jetzt können sie sehen, dass das Objekt (wahrscheinlich) eine Tabelle in der obigen Abfrage ist. Wenn wir jedoch das funktionale Äquivalent dieses Ziels schreiben, würde es so aussehen.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

Ich vermute, dass ein Kommentar weniger als nützlich aussieht, obwohl Präfixer genau dafür argumentieren. Um das nutzlose Rauschen hervorzuheben, das dieser Metadatenkommentar einfügt, sollten Sie eine kompliziertere Abfrage in Betracht ziehen.

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

Erleichtern die zusätzlichen Kommentare die Begründung dieser Abfrage oder fügen sie nur zusätzliches Rauschen hinzu? Meiner Meinung nach fügen sie nur zusätzliches Rauschen und einen Wert von Null hinzu. Das versuchen die Anti-Präfixer zu sagen. Darüber hinaus ist die Verwendung von Präfixen tatsächlich schlechter als diese Kommentare, da die Kosten für die Aktualisierung eines Kommentars viel geringer sind als für die Aktualisierung des Namens einer Präfixtabelle, wenn Ihr Datenmodell angepasst werden muss. Da diese Präfixe kostenintensiv sind und keine wertvollen Informationen liefern, sollten sie vermieden werden.

Ein weiterer Vorteil von Präfixen, die einige Leute zitieren, ist, dass sie eine Art Gruppierung oder Reihenfolge in Ihrer Entwicklungsumgebung vermitteln können. Da wir viel Zeit damit verbringen, Code zu bearbeiten, kann dies für einige ein verführerisches Argument sein. Nach meiner Erfahrung bieten moderne Entwicklungsumgebungen jedoch gleichwertige oder überlegene Optionen, die Ihren Code nicht mit nutzlosen Metadaten verunreinigen und Ihre Flexibilität einschränken.

8
Erik

Dies wurde schon oft behandelt, aber wahrscheinlich am bekanntesten von Joe Celko , einem amerikanischen Experten für SQL und relationale Datenbanken. Ich war persönlich am empfangenden Ende einer seiner Beschimpfungen online (fühlte mich geehrt), und er spricht über diese Präfixe als "tibbling" oder genauer beschrieben als " skeuomorphism ".

Die allgemeine Idee ist, dass diese Präfixe eine Codierungspraxis von vor langer Zeit sind (wahrscheinlich aufgrund von Namensbeschränkungen, wie einer 8-Byte-Beschränkung für Objektnamen), die Generationen von Programmierern ohne scheinbar nützlichen Grund weitergegeben haben, außer es ist nur "der Weg" es ist vollbracht".

Unternehmen, Blogger und Programmierer geben Informationen mit ihrem eigenen Codierungsstil weiter, und einige Stile sind möglicherweise etwas "Frankenstein" als andere. Ein Unternehmen könnte einen "Hausstil" haben, und der Programmierer ist gezwungen, diese Praxis zu lernen.

Im Laufe der Zeit bleiben die Dinge hängen, auch wenn der Grund, warum sie ursprünglich verwendet wurden, jetzt veraltet ist. "Tibbling" ist eines der bekanntesten Beispiele dafür in der relationalen Datenbankverwaltung.

Zusammenfassend: Es wird kein Wert hinzugefügt, sondern es werden genau 4 Byte Speicherplatz für jeden Tabellennamen hinzugefügt, und zwar aus keinem anderen Grund als weil er vorhanden ist. Es bietet modernen SQL Server-Systemen nichts, aber wenn Sie sich dort besser fühlen, können Sie es verwenden.

7
John Bell

Mein Vorschlag wäre, dass Sie sofort damit aufhören. Wenn Ihnen dies in Zukunft unangenehm ist, fügen Sie "_tbl" zum Ende Ihrer Tabellennamen hinzu. Natürlich besteht auch aus bereits genannten Gründen keine Notwendigkeit, dies zu tun. Die Person, die Ihnen ursprünglich gesagt hat, dass Sie das tun sollen, hat Ihnen schlechte Ratschläge gegeben. Es mag schlecht gewesen sein, "dies ist im Hinblick auf das schlecht eingerichtete System unserer Organisation sinnvoll", aber in diesem Fall war es seine Aufgabe, es zu beheben. Immer noch schlechter Rat.

5
user3131341

Ist "Stellen Sie Ihren Tabellen nicht tbl voran" wirklich ein Problem?

In Bezug auf das System? In Bezug auf andere Leute? Könnte sein. Sie können viel Hass erzeugen.

Ich persönlich stelle keine Tabellen voran, sondern andere Objekte wie Ansichten, gespeicherte Prozeduren, Funktionen usw.

3
Joe

Ich muss sagen, bitte hör auf damit. Es ist in der Vergangenheit passiert, aber wenn Sie dies weiterhin tun, ermutigen Sie neue Menschen, die in Ihre Umgebung kommen, zu glauben, es sei eine lokale Konvention, und fahren fort. Aber sie werden nicht einfach weitermachen, sie werden es etwas anders machen

Wenn Sie eine Datenbank nach einem bestimmten Element durchsuchen und nicht der einzige sind, der den Objekt-Explorer öffnet und nur denkt, dass ich dorthin scrollen werde, wissen Sie, dass es alphabetisch ist. Bis Präfixe das Wasser trüben und ich tblname, tbl_name, tbname, t_name und tausend andere Variationen habe, wird es wirklich schwierig, die Tabelle zu finden, von der Sie wissen, dass sie bereits eine Tabelle ist

Wenn Sie alles vw_ oder sp_ voranstellen, kommt jemand herein und Sie erhalten SPname, spname, s_p_name. Entfernen Sie alle Präfixe. Die Software weiß, was das Element ist. Wenn Sie es wirklich wissen müssen, verwenden Sie stattdessen ein Suffix. NameOfMyView_v, NameOfMyProc_sp. viel einfacher visuell zu suchen

Aber was ist, wenn Sie einen lange gespeicherten Prozess durchforsten und nicht leicht erkennen können, was eine Ansicht eines Prozesses oder einer Tabelle ist? Es besteht die Möglichkeit, dass diese ohnehin verfälscht werden, und selbst wenn dies nicht der Fall ist, hilft Ihnen das Suffix

Haben Sie keine Angst davor, Ihre Arbeit zu ändern, und wenn Sie in eine Umgebung gehen, in der die Namenskonventionen bereits zum Teufel sind, haben Sie keine Angst davor, Ihre eigenen zu implementieren, und beginnen Sie, die Dinge zum Besseren zu verändern. Durch die Anpassung an das vorhandene Chaos besteht keine Chance, dass es weniger verwirrend wird, sondern nur mehr

1
cockbeard