Hi!
Ich habe (mal wieder ;)) einen sachlichen Dissenz mit raist, und würd ihn eiglich lieber hier ausdiskutieren, als den Thread, wo er aufgetreten ist, damit zu überfrachten.
raist empfiehlt, alle Datenbank-Objekte mit prefix zu benennen, weil komplexes Sql dann leichter zu lesen sei.
ich empfehle, wenigstens bei Tabellen keine Prefixe zu verwenden, weil Sql dann leichter zu lesen ist (es entspricht mehr der natürlichen Sprache).
Ausserdem empfiehlt er, Tabellen als Plural zu benennen, während ich Tabellen singular benenne.
Beispiel: Gegeben die Tabellen Group und User, mit der 1:n - Relation: Group -> User.
Nun will man alle User und deren Gruppen-Namen (klassischer Inner-Join):
(ich hoffe, ich machs richtig - Sql ist nämlich nicht mein Steckenpferd ;))
Jedenfalls finde ich obige Query klar wie Klosbrühe, und kann in
nur eine Verschlechterung der Lesbarkeit finden.
Hier zeigt sich auch das (in Sql unlösbare) Problem: ist plural oder singular flexiert sinniger?
In meiner Abfrage ist der Select-Abschnitt mit singular richtig flexiert, denn der Select-Abschnitt betrachtet einen einzelnen Datensatz. Dafür muß man hinnehmen, dass der FROM - Abschnitt falsch flexiert ist, denn es wird aus einer Auflistung selektiert. Aber schon die ON-Bedingung ist wieder korrekt flexiert, weil sie betrachtet wieder den einzelnen User / die einzelne Group.
In raists System ist einzig der FROM-Abschnitt richtig flexiert, alle anderen Abschnitte sind mit plural falsch flexiert.
Perfekt wäre ein Sql, welches folgendes ermöglichte:
(Linq2Sql und Entity-Framework haben sowas drauf, allerdings nur für englisch-sprachige Bezeichner)
Wie gesagt: Ich empfehle den Verzicht auf Prefixe nur bei Tabellen - andere Datenobjekte sollen mw. "geprefixt" sein. Auf diese Weise ist die Unterscheidbarkeit der Objekte immer noch 100% sichergestellt: sehe ich einen Bezeichner ohne Prefix, so weißich, es ist eine Tabelle.
Ich muß aber gleich dazusagen: Ich hab wirklich nicht viel Ahnung von Sql - ich bevorzuge, DB-Daten in einer Data-Acces-Schicht zu laden, und alsbald in .Net-Datentypen zu konvertieren, und jegliche Datenverarbeitung dann innerhalb des TypSystems des Frameworks durchzuführen.
Schon obigen Inner Join würde ich nur in extremen Ausnahmefällen konstruieren, sondern stattdessen die Daten in verschiedene DataTables laden und erst im Formular zu einem gejointen View zusammenführen.
Ich habe (mal wieder ;)) einen sachlichen Dissenz mit raist, und würd ihn eiglich lieber hier ausdiskutieren, als den Thread, wo er aufgetreten ist, damit zu überfrachten.
raist empfiehlt, alle Datenbank-Objekte mit prefix zu benennen, weil komplexes Sql dann leichter zu lesen sei.
ich empfehle, wenigstens bei Tabellen keine Prefixe zu verwenden, weil Sql dann leichter zu lesen ist (es entspricht mehr der natürlichen Sprache).
Ausserdem empfiehlt er, Tabellen als Plural zu benennen, während ich Tabellen singular benenne.
Beispiel: Gegeben die Tabellen Group und User, mit der 1:n - Relation: Group -> User.
Nun will man alle User und deren Gruppen-Namen (klassischer Inner-Join):
Jedenfalls finde ich obige Query klar wie Klosbrühe, und kann in
Hier zeigt sich auch das (in Sql unlösbare) Problem: ist plural oder singular flexiert sinniger?
In meiner Abfrage ist der Select-Abschnitt mit singular richtig flexiert, denn der Select-Abschnitt betrachtet einen einzelnen Datensatz. Dafür muß man hinnehmen, dass der FROM - Abschnitt falsch flexiert ist, denn es wird aus einer Auflistung selektiert. Aber schon die ON-Bedingung ist wieder korrekt flexiert, weil sie betrachtet wieder den einzelnen User / die einzelne Group.
In raists System ist einzig der FROM-Abschnitt richtig flexiert, alle anderen Abschnitte sind mit plural falsch flexiert.
Perfekt wäre ein Sql, welches folgendes ermöglichte:
Wie gesagt: Ich empfehle den Verzicht auf Prefixe nur bei Tabellen - andere Datenobjekte sollen mw. "geprefixt" sein. Auf diese Weise ist die Unterscheidbarkeit der Objekte immer noch 100% sichergestellt: sehe ich einen Bezeichner ohne Prefix, so weißich, es ist eine Tabelle.
Ich muß aber gleich dazusagen: Ich hab wirklich nicht viel Ahnung von Sql - ich bevorzuge, DB-Daten in einer Data-Acces-Schicht zu laden, und alsbald in .Net-Datentypen zu konvertieren, und jegliche Datenverarbeitung dann innerhalb des TypSystems des Frameworks durchzuführen.
Schon obigen Inner Join würde ich nur in extremen Ausnahmefällen konstruieren, sondern stattdessen die Daten in verschiedene DataTables laden und erst im Formular zu einem gejointen View zusammenführen.