Schwer machen ist ja eh egal, oben ist eine Klasse verlinkt. Diese einzubinden ist ein Kinderspiel. Weiter wird der Code generiert, d.h. Singular oder Plural macht performancetechnisch keinerlei Unterschied.
Pluralization of english nouns
Einklappen
X
-
Zitat von PHP-Desaster Beitrag anzeigenSchwer machen ist ja eh egal, oben ist eine Klasse verlinkt. Diese einzubinden ist ein Kinderspiel. Weiter wird der Code generiert, d.h. Singular oder Plural macht performancetechnisch keinerlei Unterschied.
Aber man sollte auch bedenken, dass es eine zusätzliche Fehlerquelle ist. Und für was? Damit die Tabellennamen "hübscher" sind?
Ich seh da einfach keinen praktischen Vorteil, sondern nur Nachteile.
Kommentar
-
Ich würde mich da gar nicht vom Sprachgebrauch leiten lassen, weder vom deutschen noch vom englischen. Dass das Mapping von Singular auf Plural und umgekehrt nicht trivial ist (in keiner mir bekannten Sprache) ist klar. Es gibt keine 100% korrekte Lösung. Kann es nicht geben, denn Sprachen verändern sich. Es kommen neue Wörter dazu und die können Sonderfälle sein wie das o.g. child/children. Es wäre also notwendig, die Tabelle der Sonderfälle regelmäßig zu aktualisieren, um as close as possible an der perfekten Lösung zu sein. Aber wie soll die Pflege dieser Tabelle denn aussehen? Da afaik solche Listen nicht irgendwo fertig und aktuell zu bekommen sind, muss man selbst die Entwicklung der Sprache beobachten. Und wie entscheidet man, ob ein neues Wort bereits zur Sprache und damit auch in die Liste gehört? Wie stellt man sicher, dass die Liste dem Sprachschatz aller Anwender des Codes voraus ist? Geht gar nicht. Es kann keine 100% korrekte Lösung geben und für as close as possible ist Expertenwissen und regelmäßiger Aufwand nötig. Das wäre es mir nicht wert und ich würde es kategorisch ablehnen, weil es das Projekt unnötig komplexer macht und Abhängigkeiten erzeugt, die die Sache nicht wert sind.
Das Argument "Eine Tabelle enthält mehrere Datensätze, stellt also definitiv einen Plural dar" basiert auf der Ansicht, dass der Tabellenname bezeichnen muss, wie viele Datensätze die Tabelle enthalten kann. Es wurde bereits erwähnt, dass jede Tabelle immer mehrere Datensätze enthalten kann. Die Anzahl möglicher Datensätze muss also gar nicht im Tabellennamen ausgedrückt werden - es gibt nur eine Möglichkeit. Wenn der Name etwas ausdrücken soll, dann die Kardinalität bei Verknüpfungstabellen. Wenn! Er muss es nicht. Das kann man auch wo anders notieren, so dass ein Generator damit arbeiten kann; beispielsweise als Kommentar (INFORMATION_SCHEMA.TABLES.TABLE_COMMENT).
Statt viel Arbeit, mehr Komplexität und Abhängigkeiten für eine niemals perfekte Lösung, plädiere ich eindeutig für eine ganz einfache Lösung, die nur dahingehend nicht perfekt ist, dass man eine bestimmte Ansicht über die Aussagekraft von Tabellennamen haben muss, um es als korrekt aufzufassen.
Kommentar
-
Prinzipiell stimme ich dem pragmatischen Ansatz zu, alles im Singular zu halten. Praktisch wirft das, jedenfalls bei mir, ein paar Probleme auf. Die Item-Controller sollten weiterhin im Plural verfasst sein. Warum? Es sieht schöner aus! Bringt das was? Genau so viel wie eine sprechende Adresse eben bringt.
Trotzdem bin ich mehr und mehr vom "alles Einzahl" überzeugt.
Kommentar
-
Zitat von unset Beitrag anzeigenPrinzipiell stimme ich dem pragmatischen Ansatz zu, alles im Singular zu halten. Praktisch wirft das, jedenfalls bei mir, ein paar Probleme auf. Die Item-Controller sollten weiterhin im Plural verfasst sein. Warum? Es sieht schöner aus! Bringt das was? Genau so viel wie eine sprechende Adresse eben bringt.
Trotzdem bin ich mehr und mehr vom "alles Einzahl" überzeugt.
Was ist wenn irgendwann die Anforderung kommt, dass die Adressierung nicht in der Mehrzahl sondern in der Einzahl erfolgen soll? Oder wenn die Items plötzlich nicht mehr Items sondern Articles heißen sollen? Schreibst du dann deine Controller, Models, Datenbanktabellen und alles was darauf verweist um? Und was ist bei Mischfällen?Zuletzt geändert von h3ll; 19.11.2009, 18:57.
Kommentar
-
Zitat von h3ll Beitrag anzeigenDie Adresse kannst du ja als Route festlegen. Wie bereits gesagt, es reicht wenn es für den Endbenutzer schön ausschaut. Warum willst du deine Programmstruktur an die Regeln der Ausgabe und Adressierung richten? Die haben damit ja nicht wirklich was zu tun.
Zitat von h3ll Beitrag anzeigenWas ist wenn irgendwann die Anforderung kommt, dass die Adressierung nicht in der Mehrzahl sondern in der Einzahl erfolgen soll? Oder wenn die Items plötzlich nicht mehr Items sondern Articles heißen soll? Schreibst du dann deine Controller und alles was darauf verweist um? Und was ist bei Mischfällen?
Wenn ich eine Tabelle umbenenne muss ich nichts anpassen (solange sie derzeit weiterhin in der Mehrzahl vorliegtund abgesehen von den auf diese Tabelle zeigenden FKs), da sich alle Adressen/Routen/Controller/Module halt dynamisch generieren. Zur verdeutlichung: Ich lege eine Tabelle Namens "shop_products" an, woraufhin automatisch ein Modul Namens "Shop" existiert, ein Controller Namens "Products" ein Modell namens "Products" ... dieser Controller hat - wie eingangs schon erwähnt - eine Reihe typischer Actions wie edit, delete, add, move, view, list, etc. All das rein virtuell über eine Methode die ich einfach mal "showOffAs" getauft habe. D.h. der so erzeugte Controller ist in wirklichkeit eine Instanz von Controller_Action_Generic, wird er gefragt, von welcher Klasse er eine Istanz ist, behauptet er allerdings Module_Shop_Controller_Products (nur falls gefragt wird: gefragt wird sowas im ganzen System über eine in einem allgemein gültigen Interface definierte Methode).
Kommentar
-
Zitat von wahsaga Beitrag anzeigenOder wenn der Kunde einen deutschsprachigen Shop betreiben will, und lieber Produkt statt Product im URL sehen möchte ...
Kommentar
-
Zitat von unset Beitrag anzeigenDas sich das alles dynamisch zusammenbaut eben schon. Es gibt physisch keinen "Items"-Controller, lediglich eine Tabelle namens "items" (das ist jetzt etwas vereinfacht). D.h. ich muss zumindest beim erstellen oder auswerten der Route in irgend eine Richtung Plurali- oder Singularisieren - denn die sind eben auch dynamisch.
WENN diese Anforderung kommt, kann ich es immer noch über von Hand geschriebene Routen lösen ... das wäre aber in der Tat ein Sonderfall, da sich das ganze System ansonsten an den Convetion over Configuration Grundsatz hält.
Wenn ich eine Tabelle umbenenne muss ich nichts anpassen (solange sie derzeit weiterhin in der Mehrzahl vorliegtund abgesehen von den auf diese Tabelle zeigenden FKs), da sich alle Adressen/Routen/Controller/Module halt dynamisch generieren. Zur verdeutlichung: Ich lege eine Tabelle Namens "shop_products" an, woraufhin automatisch ein Modul Namens "Shop" existiert, ein Controller Namens "Products" ein Modell namens "Products" ... dieser Controller hat - wie eingangs schon erwähnt - eine Reihe typischer Actions wie edit, delete, add, move, view, list, etc. All das rein virtuell über eine Methode die ich einfach mal "showOffAs" getauft habe. D.h. der so erzeugte Controller ist in wirklichkeit eine Instanz von Controller_Action_Generic, wird er gefragt, von welcher Klasse er eine Istanz ist, behauptet er allerdings Module_Shop_Controller_Products (nur falls gefragt wird: gefragt wird sowas im ganzen System über eine in einem allgemein gültigen Interface definierte Methode).
http://example.org/shop/product/Gummistiefel
http://example.org/person/edit/2
http://example.org/myprofile/show
http://www.php-resource.de/forum/php-developer-forum/
Warum sollte man diese Begriffe in der Mehrzahl schreiben? Sieht doch komisch aus:
http://example.org/shops/products/Gummistiefel
http://example.org/persons/edit/2
http://example.org/myprofiles/show
http://www.php-resource.de/foren/php-developer-forum/
Und wenn mal wirklich die Ausnahmeanforderung kommt, dass es in der Mehrzahl geschrieben wird, kann man immer noch eine Route festlegen (oder es mit einer anderen Methode lösen).Zuletzt geändert von h3ll; 19.11.2009, 19:22.
Kommentar
-
So aus dem Stehgreif hab ich schon ein paar Realwelt-Beispiele, wo das anders ist:
http://es.technorati.com/people/unset
http://twitter.com/unset/favorites
http://games.shop.ebay.de/
Aber wie ich schon sagte, ich stimme dem Singular-Ansatz ja zu
Kommentar
-
Zitat von unset Beitrag anzeigenAll das rein virtuell über eine Methode die ich einfach mal "showOffAs" getauft habe. D.h. der so erzeugte Controller ist in wirklichkeit eine Instanz von Controller_Action_Generic, wird er gefragt, von welcher Klasse er eine Istanz ist, behauptet er allerdings Module_Shop_Controller_Products (nur falls gefragt wird: gefragt wird sowas im ganzen System über eine in einem allgemein gültigen Interface definierte Methode).
Vor allem beim letzten Satz sprangen mir sofort Type Hinting und Debugging in den Kopf. Type Hinting brauchst du vielleicht für diese Klassen gar nicht bzw. es gibst nur die allen automatisch erzeugten Klassen gemeinsame Basisklasse an. Aber beim Debugging könnte es doch stören, wenn immer Controller_Action_Generic gemeldet wird. Kommt halt darauf an, wieviel Code die virtuellen Klassen gemeinsam haben. Wenn sie alle gleich sind, machts keinen Unterschied. Sind sie das?
Nicht zuletzt interessiert mich auch, wie du die Klassen erzeugst. Vermutlich erstellst du nur Instanzen von Controller_Action_Generic und setzt per Ctor den "virtuellen Typ", den die Methode showOffAs zurückgibt. Die virtuellen Klassen werden also ohne weitere Kosten zur Laufzeit erzeugt. Die zu erzeugenden Typen weißt du aus der URL. Aber du musst doch prüfen, ob es auch die zugehörige Tabelle gibt. Das kostet was.
Ich finde die Bezeichnung virtuelle Klasse übrigens unpassend, denn wenn es so ist wie ich glaube, gibt es nur die Klasse Controller_Action_Generic.
Vielleicht ahnst du es schon: Ich will darauf hinaus, dass es möglicherweise besser wäre, statt virtuellen Klassen echt Ableitungen von Controller_Action_Generic zu erzeugen und als Datei zu speichern.
Falls es irgendwen stört, dass ich hier so vom Thema abweiche, sagt bescheid. Dann trenne ich ab.
Kommentar
-
Zeigen kann ich den Code leider nicht. Noch jedenfalls ... ich arbeite derzeit privat an einer offenen Iteration des Konzeptes. Ich hoffe, ihr habt dafür Verständnis, auch wenn ich konkret zu diesem Closed Source Code eine Frage habe.
Das überprüfen der Tabellen kostet, ja. Aber auch nur genau ein mal beim Deploy auf den Live-Server, da wird die Datenbankstruktur einmal ausgelesen, gepuffert und bis zum nächsten Deploy verwendet. Ohne Deploy keine Veränderung an der Datenstruktur.
"Virtuelle Klasse" ist ind der Tat etwas doof gewählt, eine Ableitung ist es allerdings auch nicht wirklich. Ich wweiß leider nicht, wie man es besser ausdrücken könnte.
Type Hinting nutze ich schon exzessiv, allerdings nur auf die Basis-Klassen (statt konkretem Modell halt auf das generische - es sei denn, es existieren konkrete).
Ansonsten hast du das alels schon richtig impliziert.
Beim Debugging hatte ich derzeit keine Probleme. Da ich im Fehlerfall ja auch die kompletten Traces habe, sehe ich ja auch, als was sich die Klassen ausgeben. Seit dem ich vor kurzem allerdings ebenso dynamische Tests für alle möglichen Konstellationen der generischen Geschichten geschrieben habe, komme ich an der Stelle gar nicht mehr in irgendwelche Bedrängnis. Lediglich konkrete Implementationen mit veränderten oder ergänzten Methoden müssen von Hand geschrieben werden.
Ich würde die Diskussion dahingehend allerdings gerne auf den Zeitpunkt verschieben, an dem ich eine öffentliche Version anbieten kann - denn ich hab selbst bei meinen Kollegen Probleme, an einem Stück zu erklären, wie das ganze Funktioniert - und die können sich den Code angucken
Kommentar
Kommentar