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

Im Internet habe ich einige Blogs gefunden, die sagten, es füge nichts zur Dokumentation hinzu und auch, dass "es länger dauert, es zu lesen".

Fragen und Überlegungen

• Ist das wirklich ein Problem? Weil ich seit meinem ersten DBA-Job Tabellen mit dem Präfix 'tbl' versehen habe (der leitende DBA hat mir geraten, das für die Organisation zu tun).
• Ist das etwas, das ich loswerden muss? Ich habe einige Tests durchgeführt, einen wirklich großen Tisch kopiert und ihm das Präfix 'tbl' gegeben, während ich den anderen ohne das Präfix belassen habe, und ich habe keine Performance-Probleme bemerkt.

Ich hatte einmal einen Tisch und es war glänzend und schön. Es hielt alle finanziellen Transaktionen für eine Organisation. Und dann luden wir Daten hinein.

Im aktuellen Monat können sie Werte beliebig oft angeben und anpassen. In den letzten 10 Tagen eines Monats wurden die Zahlen angepasst -> ETL-Verarbeitung ausgeführt -> Berichte mehrmals täglich überprüft. Nach Ablauf des Monats sind die Bücher versiegelt und können keine Werte mehr ändern.

Es ist erstaunlich, wie viele Finanzdaten ein Finanzdienstleistungsunternehmen generiert ... Was wir mit unserem Testdatensatz nicht realisiert haben, war, dass das Datenvolumen die Verfahren zum Monatsende unhaltbar machen würde. Es dauerte immer länger, bis die "aktuellen Monatsdaten" gelöscht waren, bevor sie durch den neuen Testlauf ersetzt wurden.

Wir mussten etwas tun, um die Verarbeitung zu beschleunigen, ohne die nicht katalogisierte Liste der "Wer weiß was" zu unterbrechen, die alle von der MonthlyAllocation-Tabelle abhängt. Ich beschloss, Zauberer zu spielen und die Tischdecke unter ihnen hervorzuziehen. Ich bin in die alte Schule gegangen und habe eine partitionierte Ansicht verwendet . Die Daten hatten bereits ein IsComplete-Flag, daher erstellte ich zwei Tabellen mit entgegengesetzten Überprüfungsbedingungen: MonthlyAllocationComplete, MonthlyAllocationInComplete

Anschließend habe ich die partitionierte Ansicht mit demselben Namen wie die Originaltabelle erstellt: MonthlyAllocation. In Bezug auf die physische Änderung, die wir an der Datenbank vorgenommen haben, war kein Prozess vernünftiger. Es wurden keine Berichte veröffentlicht. Keiner der Analysten mit direktem Zugriff hat zuvor oder nachher Probleme mit dieser "Tabelle" gemeldet.

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 durchzuarbeiten und sie zu aktualisieren, um vw_MonthlyAllocation zu verwenden? Und dann durchlaufen natürlich alle diese Änderungen 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 als tbl_ belassen und nicht die ganze Zeit damit verbringen, Code zu testen, zu aktualisieren und bereitzustellen. Was zu einer amüsanten Anekdote wird, die Sie allen neuen Mitarbeitern und Mitarbeitern mit kurzen Aufmerksamkeitsspannen erklären, die mit der Datenbank arbeiten müssen, um festzustellen, warum Sie nicht mit der Benennung von Objekten übereinstimmen

Oder Sie verschlüsseln Objekte nicht doppelt mit redundanten Metadaten. Die Datenbank teilt Ihnen gerne mit, was eine Tabelle, eine Ansicht, eine Tabellenwertfunktion usw. ist.

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

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

Der Grund, warum ich Ihnen sage, dass Sie tbl nicht vor Ihre Tabellennamen setzen sollen, ist derselbe Grund, warum ich sagen würde, dass Sie child nicht vor den Namen Ihres Kindes setzen sollen. Sie nennen sie nicht childJohn und childJane. Es bringt nicht nur keinen Mehrwert, sondern ist möglicherweise auch kein Kind im späteren Leben - und Ihre Objekte werden möglicherweise später zu Ansichten.

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

In wie vielen Szenarien sehen Sie Code und können nicht sagen, ob es sich um eine Tabelle oder etwas anderes handelt?

Welchen Wert fügt tbl hinzu, außer dass Sie beim Anzeigen einer Liste von Tabellen im Objekt-Explorer mehr Arbeit leisten müssen, um die gewünschten 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 das wichtig ist, warum nicht Ansichten auf besondere Weise benennen ? In den meisten Fällen verhalten sie sich wie Tabellen, daher sehe ich wenig Wert in der Unterscheidung.

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 tbl_whateverund die andere Hälfte den Namen "normal" - sie haben offensichtlich Entwickler, die nach unterschiedlichen Standards arbeiten. Eine weitere schlechte Angewohnheit ist das Präfixieren von Spaltennamen, die Fremdschlüssel sind fk, gefolgt vom Tabellennamen und fkdem Spaltennamen, was so schlimme Spaltennamen wie ergibt 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, die Spaltennamen voranstellen ... dtPaymentDate, weil der Name das dtPräfix wirklich benötigt ? `

comDon't verListen prepTo adjThose adjOther nouPeople. ProYou AuxSollte immer NouPrefixes verwenden, die mit ProYour einstellbaren NouNames vorbelegt sind. ProI AuxHave AdvEven VerStarted GerUsing ProThem PrepIn AdjNormal NouWriting.

comSee advHow adjEffective ProIt VerIs? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

Die Verwendung eines solchen Präfixes wird als ungarische Notation bezeichnet . Die Prämisse ist einfach: Sie können bestimmen, was etwas ist, indem Sie den Namen eingeben. Dies ist besonders häufig in Programmiersprachen der Fall, insbesondere wenn Entwickler monolithische Funktionen schreiben, die sich über Dutzende von Seiten erstrecken, entweder aufgrund mangelnder Kenntnisse oder aufgrund fehlender Sprachfunktionen. Es ist eine mnemonische Hilfe, die Entwicklern hilft, Datentypen gerade zu halten.

Im Allgemeinen wird diese Art der Benennung wahrscheinlich in wirklich altem Code verwendet, oder von Entwicklern, die entweder nur lernen (und zufällig diese Gewohnheit gelernt haben) oder es 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 Lernprogramm eingeführt werden. Sie verwenden eher Variablennamen wie i oder x oder 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 eine Datenmenge handelt (bei der es sich möglicherweise um eine Tabelle, eine Ansicht usw. handelt). Obwohl dies eine großartige Lehrhilfe sein könnte, sollte diese Syntax in Produktionsdatenbanken normalerweise nicht vorhanden sein. Dies kann die Lesbarkeit beeinträchtigen und es schwieriger machen, die gesuchte Tabelle zu finden, insbesondere wenn mehrere alternative Benennungsthemen angezeigt werden, z. B. tbl vs. table vs. tab usw.

Der Datenbank ist es eigentlich egal, wie Sie Ihre Tabellen, Felder usw. nennen. Es handelt sich nur um Datenbytes, die von ihren menschlichen Operatoren oder Skripten in einer bestimmten Reihenfolge angeordnet werden. 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. "show table like 'a%'". Die Verwendung von Präfixen und Suffixen kann die sonst triviale Wartung unnötig erschweren.

Nachdem ich meine erste SQL Server-Instanz geerbt und festgestellt habe, dass viele Objekte mit Präfix versehen sind, habe ich einige Blog-Posts wie diesen oder diesen gelesen (es gibt einige). viel einfacher für mich ( und möglicherweise auch für andere Entwickler ), an Object Relational Mapping zu arbeiten.

Eines der am häufigsten verwendeten Präfixe war Tbloder tbl, aber dann hatte ich TBLund tbl_und sogar*TableName*_Tbl

Bei dem Versuch, in Visual Studio abzufragen und zu arbeiten, ist das nur die Hölle. Es wäre mir egal, wenn ein ganzer Tabellensatz vorangestellt würde, tblaber 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 sich viele Menschen darüber freuen, dass Sie es zumindest während Ihrer Entwicklung beibehalten.

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

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 letztendlich zu etwas anderem . (zB Tabelle tblXxxwurde in tblXxxYund tblXxxZaus irgendeinem Grund aufgeteilt und durch eine Ansicht ersetzt, die die beiden neuen Tabellen verbindet. Nun haben Sie eine Ansicht namens tblXxx).
2. Wenn Sie tblim Editor tippen, bleibt die AutoVervollständigen-Funktion 45 Sekunden lang hängen und zeigt 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 seltene 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 auf Entitäten basierendes 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 Altsystem. Wir entwickeln es ständig weiter).

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

Nun möchten wir, dass die Objekte, die zu derselben Entität gehören, denselben Namen haben, aber dennoch von Zweck und Typ unterschieden werden können. Wenn wir also zwei Entitäten haben, die benannt sind CustomerOrderund CustomerInvoice, haben wir folgende Objekte:

1. Tabellen zum Speichern von Daten [ TABSuffix]:
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. Ansichten, die von Clients verwendet werden [Kein Suffix]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. Schnittstelle für grundlegende Operationen; (PL / SQL-Pakete) [ APISuffix]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Berichtsgeneratoren; (PL / SQL-Pakete) [ RPISuffix]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Indizes für Primärschlüssel [ PKSuffix]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. Sekundärindizes [ IXSuffix]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(wo XXXbeschreibt die Verwendung des Index).
7. ... und so weiter.

Dies ist in der Tat eine Form von Apps ungarischen (beachten Sie, dass gleiche Art von Objekten unterschiedliche Endungen haben kann , abhängig vom Zweck). Aber mit einem Suffix anstelle eines Präfix. Ich kann Ihnen gar nicht genug sagen, wie einfach dieses System zu lesen ist. IntelliSense funktioniert tatsächlich, da TBLich nicht 4000 Ergebnisse eingeben und abrufen muss, sondern Customeralle Objekte eingeben und abrufen kann, die zu den genannten Entitäten gehören Customer*.

Hier habe ich Ihnen gezeigt, wie nützlich Metadaten sein können . Der Zweck besteht darin, eine verwandte Menge von Datenbankobjekten zu haben, die durch einen einzelnen Namen identifizierbar sind, sie jedoch basierend auf ihrem Zweck unterscheiden .

Having said that, wenn Sie diese Art von System nicht haben, gibt es keine Verwendung von entweder prefixing oder suffixing das ist Art von Objekt .

Beachten Sie, dass wir keine Suffixe wie _table, _packageoder _view(dh den Typ des Objekts) verwendet haben. 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 dem Zweck als auf dem Typ .

Es fügt (sehr wahrscheinlich) redundante Informationen hinzu, was zu einem kognitiven Overhead führt, und sollte daher entfernt werden.

Kontext ist eine wunderbare Sache, besonders in Computersystemen. Außerhalb des Kontexts konnte man unmöglich feststellen, ob userses sich bei einem aufgerufenen Objekt um eine Tabelle, eine Ansicht, eine gespeicherte Prozedur oder um etwas ganz anderes handelt. Veraltete (oder nur schlecht geschriebene) Systeme und Sprachen erschweren es oft, den Kontext beim Lesen des Codes zu ermitteln. In Bash können Sie beispielsweise nicht sagen, was function usersfunktioniert, ohne zumindest den Inhalt der Funktion zu lesen. In Java Map<Uid,UserDetails> users()ist es ziemlich transparent, und Sie können sich leicht auf die Details konzentrieren.

Wenn Sie dieses Argument für SQL-Tabellen verwenden, wann ist es für die Verbraucher hilfreich userszu wissen, ob es sich um eine Tabelle oder eine Ansicht handelt? Mit anderen Worten, wird ein tblPräfix einem der Verbraucher etwas mitteilen, das er nicht kennt und wissen muss?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 ungefähr so ​​relevant sein, wie ob sie partitioniert, auf einer Festplatte oder einer SSD gespeichert oder in anderen technischen Details enthalten 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 zum Wohle der Minderheit zu verschmutzen, die wirklich weiß, wie man im Schema navigiert und alle technischen Details abruft.

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 Speichervolume. Es ist Aufgabe des DBMS, eine Zuordnung zu der anderen vorzunehmen. Es ist nur für den DBA oder den Systemadministrator von Belang, welche Hardware den Informationsbedarf unterstützt. Der Verbraucher braucht sich dieser Bedenken nicht bewusst zu sein.

Der Client sollte sich auch keine Gedanken darüber machen, wie ein Rowset aufgebaut ist. Eine Basistabelle, eine Sicht 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 ist sich jetzt der Interna des Servers bewusst und von diesen abhängig. Eine Änderung der Server-Codierung kann eine Überarbeitung des Clients erforderlich machen.

Hier gibt es 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 Aussage wähle ich drei Spalten von etwas aus, das benannt wird dbo.foo. Eine der Hauptbeschwerden der Präfixe ist, dass sie nicht wissen, ob dbo.fooes sich um eine Tabelle oder eine Sicht handelt. Das ist natürlich eine der Stärken einer Sichtweise als Abstraktion, aber ich schweife ab. Sie sagen, wir sollten das Objekt so 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 Kommentar weniger als nützlich aussieht, obwohl Präfixe effektiv dafür plädieren. Um das nutzlose Rauschen hervorzuheben, das dieser Metadatenkommentar einfügt, wird eine kompliziertere Abfrage in Betracht gezogen.

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 das Begründen dieser Abfrage, oder fügen sie nur zusätzliches Rauschen hinzu? Meiner Meinung nach fügen sie nur zusätzliches Rauschen und Null hinzu. Das versuchen die Anti-Präfixe 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 wesentlich geringer sind als für die Aktualisierung des Namens einer Präfixtabelle, wenn Ihr Datenmodell angepasst werden muss. Da diese Präfixe Kosten verursachen und keine wertvollen Informationen enthalten, sollten sie vermieden werden.

Ein weiterer Vorteil von Präfixen, den einige Leute zitieren, ist, dass sie eine Art Gruppierung oder Ordnung in Ihrer Entwicklungsumgebung vermitteln können. Da wir viel Zeit damit verbringen, Code zu bearbeiten, kann dies für manche 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.

Dies wurde viele Male behandelt, aber wahrscheinlich am berühmtesten von Joe Celko , einem amerikanischen SQL- und relationalen Datenbankexperten. Ich war persönlich am empfangenden Ende eines seiner Rants online (ich fühlte mich geehrt) und er spricht über diese Präfixe als "tibbling" oder genauer als " skeuomorphism ".

Die allgemeine Idee ist, dass diese Präfixe eine Codierungspraxis von langer Zeit sind (wahrscheinlich aufgrund von Namensbeschränkungen, wie einer 8-Byte-Beschränkung für Objektnamen), die Generationen von Programmierern ohne anscheinend nützlichen Grund weitergegeben wurden, 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 "Frankensteiner" 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 bestehen, auch wenn der Grund, aus dem sie ursprünglich verwendet wurden, mittlerweile veraltet ist. "Tibbling" ist eines der bekanntesten Beispiele für relationales Datenbankmanagement.

Um es abzurunden: Es addiert keinen Wert, sondern genau 4 Byte Speicherplatz für jeden Tabellennamen, und zwar aus keinem anderen Grund als weil er da ist. Es bietet modernen SQL Server-Systemen nichts, aber wenn Sie sich dort besser fühlen, können Sie es verwenden.

Mein Vorschlag wäre, dass Sie sofort damit aufhören. Wenn Sie sich dadurch unwohl fühlen, fügen Sie "_tbl" am Ende Ihrer Tabellennamen hinzu. Natürlich besteht aus den bereits genannten Gründen auch keine Notwendigkeit dazu. Die Person, die Sie ursprünglich dazu aufgefordert hat, hat Ihnen einen schlechten Rat gegeben. Es mag schlecht gewesen sein, "das macht Sinn in Bezug auf die schlecht eingerichteten Systemratschläge unserer Organisation", aber in diesem Fall war es seine Aufgabe, das Problem zu beheben. Immer noch schlechter Rat.

Ist "Tabellen nicht mit tbl voranstellen" wirklich ein Problem?

Bezüglich des Systems? Bezüglich anderer Leute? Vielleicht. Sie können viel Hass erzeugen.

Ich persönlich füge keine Tabellen als Präfix hinzu, sondern andere Objekte wie Ansichten, gespeicherte Prozeduren, Funktionen usw.

Ich müsste 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 der Annahme, dass es sich um eine lokale Konvention handelt, und machen Sie weiter. Aber sie werden nicht einfach weitermachen, sie werden es etwas anders machen

Wenn Sie eine Datenbank nach einem bestimmten Element durchsuchen und ich bin nicht der Einzige, der den Objekt-Explorer öffnet und denkt, ich scrolle dorthin, wissen Sie, dass es alphabetisch ist. Das ist, bis Präfixe beginnen, das Wasser zu trüben, und ich habe tblname, tbl_name, tbname, t_name und tausend andere Variationen, es wird wirklich schwierig, diese Tabelle zu finden, von der Sie wissen, dass sie bereits eine Tabelle ist

Ebenso wird alles mit dem Präfix vw_ oder sp_ versehen, und jemand wird hereinkommen und Sie erhalten SPname, spname, s_p_name. Entfernen Sie alle Präfixe, die Software weiß, was das Element ist. Wenn Sie 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 ein Prozess oder eine Tabelle ist? Die Chancen stehen gut, dass diese ohnehin verzerrt sind, und selbst wenn das Suffix nicht zu Ihrer Rettung kommt

Haben Sie keine Angst davor, das zu ändern, was Sie tun, und wenn Sie in eine Umgebung eintreten, in der die Namenskonventionen bereits zum Teufel festgelegt sind, haben Sie keine Angst davor, Ihre eigenen zu implementieren, und beginnen Sie, Dinge zum Besseren zu ändern. Durch die Übereinstimmung mit dem vorhandenen Chaos besteht keine Chance, dass es weniger verwirrend wird, sondern nur mehr

Wenn ich über den Vorteil nachdenken muss, dass ich das Präfix 'tbl' habe, kann ich im aktuellen SSMS mit Intellisense einfach tippen

select * from tbl

und dann finde den Tabellennamen, den ich brauche (vorausgesetzt, ich habe keine Ahnung über den genauen Tabellennamen). Dies ist eine einstufige Arbeit. Natürlich können wir immer die Tabellennamen durch zusätzliche Schritte herausfinden, aber ich würde mit ‚Tabl‘ prefix sage , dass dies das ist ONE Arbeitsschritt, und das ist , warum immer ich einen Präfix (nicht unbedingt ‚Tabl‘) lieber in mein eigenes Hausaufgabenprojekt.

Bearbeiten : (Nach so vielen Abstimmungen halte ich es immer noch für sinnvoll, auf einige Nischenvorteile hinzuweisen, die es mit sich bringen, einer bestimmten Kategorie von Objekten in SQL Server ein bestimmtes Präfix zuzuweisen.) Es scheint, dass sich niemand über ein Präfix für gespeicherte Prozeduren / Funktionen / Ansichten beschwert, aber es gibt immer Argumente dafür, dies mit Tabellen zu tun. (Für mich ist es in der realen Welt gleichgültig, ob wir Tabellen ein Präfix geben oder nicht).

Ich erinnere mich, dass es in SQL Server 2005-Tagen eine Anforderung gab, herauszufinden, welche Tabellen in welchen gespeicherten Prozeduren / Ansichten mit vorangestellten Tabellennamen verwendet werden. Mit Regular Expression / C # war dies eine so einfache Aufgabe. (Ja, ich weiß, es gab andere Wege, kein Argument hier).

Meine Karriere wächst mit dem Lesen vieler "Best Practices" -Papiere / -Artikel, aber ich habe auch genug Ausnahmen zu fast allen "Best Practices" in der einen oder anderen Weise in verschiedenen Szenarien gesehen. So sage ich mir und meinen DBA-Kollegen immer, das Urteil richtet sich nach den geschäftlichen Anforderungen, "Best Practice" hat seinen Platz, kann aber nur im Kontext unserer eigenen Umgebung betrachtet werden.

Betrachten dbo.Uservs dbo.tUser. Stellen Sie sich nun vor, Sie möchten alle Stellen im Code finden, an denen diese Tabelle verwendet wird. Welche Version macht dies einfacher (oder sogar möglich?). Das Wort "Benutzer" enthält wahrscheinlich viele falsche Positive, wie Variablennamen, Kommentare usw.

Das ist etwas, was ich in keiner der anderen Antworten gesehen habe, aber ich bin ein Entwickler mit Datenbankadministrator. Vielleicht mussten andere nicht an altem Code arbeiten, in dem Abfragen in die Anwendung eingebettet werden können, und nicht an allen Abfragen qualifizieren Referenzen mit dem Schema vollständig, und solche Dinge. (Auch wenn alles voll qualifiziert ist, müssen Sie dbo.Userund [dbo].[User]und dbo.[User]und finden ). Oder Datenbankversionen, bei denen die "Abhängigkeitsinformationen" veraltet und ungenau sind (zB ältere Versionen von MS-SQL)

Bei einigen Projekten, an denen ich gearbeitet habe und die so gemischt sind, habe ich ein toder ein vPräfix (tbl_ wird albern) angegeben, um den Suchbegriff selektiver zu gestalten.

In späteren Projekten mit SQL Server-Datentools (Hallo, Alle Verweise suchen) und Datenbankzugriff ausschließlich über eine ORM-Ebene gibt es kein Dienstprogramm, da das Suchen aller Verwendungen der Tabelle trivial ist (wie das Umbenennen!).

Jede Seite hat ihre Vor- und Nachteile. Es liegt nur an Ihrem Team oder Ihrer Firma, welche Konventionen zu befolgen sind.

Wir nutzen zum einen die tblKonvention. Der Hauptgrund ist, dass wir in Skripten wissen, was wir tun können und was nicht. Wir haben abwechslungsreiche Projekte und Menschen, die das Schema nicht auswendig können. Unsere Tabellen haben logische Namen, sodass Sie sich beim Schreiben von Skripten leicht zurechtfinden. Wenn wir dabei eine Tabelle finden, wissen wir sofort (über IntelliSense), dass es sich um eine Tabelle handelt. Man kann argumentieren, dass das Hinzufügen des Präfix nicht viel Kontext hinzufügt. Entfernen bedeutet jedoch, dass es keinen Kontext gibt.

Der einzige wirkliche Vorteil, wenn Sie das Präfix nicht verwenden, ist die Austauschbarkeit. Ich würde jedoch argumentieren, dass dies eine potenziell gefährliche Situation ist. Sicher, Ihre Skripte und Abfragen werden nicht kaputt gehen, aber vielleicht verlassen Sie sich zu sehr auf diese Tatsache, während einige Dinge einfach nicht mit Ansichten funktionieren oder schlecht beraten sind.

Am Ende geht es nur darum, was Ihr Team bevorzugt und wie es Code / Skripte schreibt.

Früher hatte ich einen Grund, Tabellennamen mit "tbl" zu versehen. Wenn Sie sich eine Liste von Datenbankobjekten ansehen, können Sie diese Abfrage ausführen:

select * from sysobjects

Wenn Sie nur Tabellen erhalten möchten, können Sie dies tun:

select * from sysobjects where type = 'U'

Wer kann sich daran erinnern? Wenn Ihre Tabellennamen alle mit "tbl" beginnen, können Sie diese Abfrage verwenden, bei der Sie sich die Werte der Typenspalte nicht merken müssen:

select * from sysobjects where name like 'tbl%'

Da Sie SQL Server 2014 mit Tags versehen haben, gilt dies nicht für Sie, da Sie ab SQL Server 2005 stattdessen Folgendes ausführen können:

select * from sys.tables

Ich kann mir keinen anderen Grund für das Präfixieren von Tabellennamen vorstellen.