Am 3.11.2014 17:12, schrieb g4-l...@tonarchiv.ch:
> On 11/03/2014 04:53 PM, bernd wilke wrote:
>> > Am 03.11.14 16:08, schrieb g4-l...@tonarchiv.ch:
>>> >> Hallo Liste,
>>> >>
>>> >> ich versuche folgendes Konstrukt umzusetzen:
>>> >>
>>> >> Das Mutterobjekt "Konzern" hat mehrere Unterobjekte "Standorte". Diese
>>> >> Standorte wiederum habe Abteilungen.
>>> >> Soweit so gut.
>>> >>
>>> >> Nun gibt es aber auch Abteilungen, die direkt dem Konzern untergeordnet
>>> >> sind. Jetzt könnte ich natürlich einfach der Klasse "Konzern" auch eine
>>> >> Relation "Abteilung" hinzu fügen.
>>> >> Ich fände es aber hübscher, wenn alle Abteilungen auf der gleichen Ebene
>>> >> eingebunden sind. Daher würde ich einfach einen "Dummy-Standort" hinzu
>>> >> fügen, der die Abteilungen des Konzerns vereint.
>>> >> Spricht etwas dagegen, diesem Standort eine negative UID zu geben, damit
>>> >> er dadurch von den normalen Standorten unterscheidet werden kann? Ist
>>> >> das überhaupt möglich?
>> >
>> > hm. implizite Sonderregeln sind immer eine Gefahr.
>> >
>> > wenn ich mir aktuell ansehe was für Probleme es mit Flux,Gridelements
>> > gibt: negative colPos-Werte für CEs wenn sie in einem anderen Element
>> > eingebunden sind (IRRE). und auf einmal verrutschen Elmeente aus der
>> > hauptspalte (colPos=0) ins Nirwana (colPos = -1 ohne Parent)
>> >
>> > oder vor 15 Jahren mit Geburtsjahr = '99' für unbenutzt. Das war noch
>> > viel schlimmer als Y2K.
>> >
>>> >> Die andere Variante wäre wohl einfach eine boolsche Property
>>> >> "isKonzern" ...
>> >
>> > klingt viel vernünftiger.
>> > oder ("do not display division")
>> >
>> > bernd
> Was ist mit "do not display division" gemeint? Ist das auch ein Flag?
>
>
Vielleicht solltest du bei der Lösung deines Problems die Idee des
Domain Driven Development berücksichtigen.
Wie werden diese Abteilungen im Konzern von den Verwaltungsleuten bzw.
von den Redakteuren bezeichnet? Sind die Stabstellen, also die
Abtteilungen des Konzerns, gleichrangig zu den anderen Standortendann
solltest du einen Standort 'Konzern' mit dem boolschen Parameter
isKonzern einrichten. Haben die Konzernabteilungen dagegen besondere
Rechte und einen höheren Status, dann sollten die Abteilungen direkt als
relation beim Konzern anbringen, da diese Abteilungen gleichrangig mit
den Standorten zu behandeln sind.
Unter dem Domain Driven Aspekt sollte dein Modell nicht deinen Geschmack
sondern die Realität bzw. möglichst die Realität des allgemeinen
Sprachgebrauchs abbilden.
Gegen negative UIDs spricht praktisch, dass die UID-Werte in der
datenbank zur Absicherung der Eindeutigkeit oft autoincrement-Felder
sind, die automatisch nur aufaddiert werden
Negative UIDs verstoßen gegen die 2. Normal-Form der Datenbank, da durch
deine Idee das implizite Nichtschlüsselattribut 'isKonzern' funktional
von der UIDs abhängt.
wikipedia -
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)#Zweite_Normalform_.282NF.29
"Zweite Normalform (2NF)
Eine Relation ist in der zweiten Normalform, wenn die erste Normalform
vorliegt und kein Nichtschlüsselattribut funktional abhängig von einer
echten Teilmenge eines Schlüsselkandidaten ist."
Dieter
--
Dr. Dieter Porth -
Mein kleines TYPO3-Labor: http://www.mobger.de/
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
