Select all bei inner join

Re: Select all bei inner join

ewx hat geschrieben:Ich kann zum Beispiel auch nie MARD und MARC auseinander halten...

Das ist ganz einfach: C wie Werk, D wie Lagerort

Da zeigt sich aber, wie überlebt bestimmte Strukturen schnell sind - das Fehlen des B-Segmentes (wofür es Gründe gibt), macht die ganze Erklärung für die anderen Namen inkonsistent. Aber immerhin: Mit MA++ kann man ganz gut suchen, ebenso wie bei

ewx hat geschrieben:Und auch VBAK, VBAP, VBKD, VBPA, VBEP, VBUP, VBUK etc. können durch Aliase durchaus leserlicher werden

wo man nach VB++ suchen kann und da recht schnell was findet. Beim Durchnummerieren hat man das Problem, dass man wirklich nur eine Nummer hat und die unsystematisch vergeben wird. Da hilft dann nur eine sprechende Bezeichnung.

ewx hat geschrieben:IZudem hat Ralf ja auch nicht behauptet, dass ALIAS besser wäre, als ein Kommentar.
Beides sind Möglichkeiten, einen Join deutlicher zu machen.

Ja, aber der sprechende Bezeichner ist deshalb besser, weil ein Kommentar, der einen schlechten Bezeichner erklärt, nur eine Krücke ist. Er bereinigt das Defizit, das ein schlechter Bezeichner erst erzeugt.


Ralf

Re: Select all bei inner join

ewx hat geschrieben:

ralf.wenzel hat geschrieben: Ja, aber der sprechende Bezeichner ist deshalb besser, weil ein Kommentar, der einen schlechten Bezeichner erklärt, nur eine Krücke ist. Er bereinigt das Defizit, das ein schlechter Bezeichner erst erzeugt.

Schlechte Bezeichner sind aufgrund der beschränkten Zeichenanzahl aber die Regel.
Ausserdem sind wir immer noch Programmierer.
Ich möchte also eine effiziente Mischung zwischen wenig tippen und Erkennbarkeit erreichen.
Deswegen kann ich meinen Bezeichner einfach MWERK nennen und ihn trotzdem als "Materialstamm Werkssicht" dokumentieren.

Formell hast du recht, aber warum sollte ich MWERK nehmen, wenn ich 30 Zeichen Platz habe, um einen sprechenderen Bezeichner zu wählen, der dann bei jeder Verwendung erklärt, was drinsteht und nicht nur da, wo der Entwickler dran gedacht hat, es zu kommentieren?

material_md_plant, material_master_plant, plant_data4material......

Entweder ist der Kommentar da, um einen schlechten Bezeichner zu "kaschieren" (dann sollte man den Bezeichner verbessern) oder er ist unnötig.


Ralf

Re: Select all bei inner join

Ich muss hier echt mal loswerden, dass ich es klasse finde, dass einfache Forenbeiträge/Fragen in Grundsatzdiskussionen ausufern.

Und das meine ich absolut ernst! Bei diesen Diskussionen lese ich oft mit und kann einiges lernen, bzw. neue Ansätze kennen lernen.

Re: Select all bei inner join

Also ich finde es absoluten Schwachsinn, Standard-Tabellennamen, die den meisten Entwicklern etwas sagen, weil sie schon viel damit gearbeitet haben, durch irgend etwas anderes zu ersetzen, so dass der Entwickler dann hinten im SELECT in den Aliasdefinitionen wühlen muss, um dann den Aha-Effekt zu haben "Ach so, der liest einfach nur die MARA!". Wenn man der Meinung ist, die verwendeten Tabellen in einem SELECT irgendwie erläutern zu wollen, dann kann man das in einem Kommentar machen. Klar muss man den bei jedem derartigen SELECT wiederholen, aber das muss man bei einem SELECT-Alias genauso.

Bei eigenen Tabellen kann man dann gleich auf der Datenbank einen sprechenden Namen wählen.