nicht angemeldet
Exklusive alternative 1:n Relationen / SQL u. OOP
0 0 OO Formulierung der Problems / SQL dazu ?
0
Exklusive alternative 1:n Relationen / SQL u. OOP
Hallo !
Ich arbeite an einer >3-Schichten Architektur zur Modellierung bestimmter Geschaeftsprozesse.
Die zugehörige Datenbank ist in mehrere Bereiche gegliedert.
Im Zentruum des Modells steht eine Tablle "Situationen" (S)
Ohne zeitliche Dimension
------------------------
- Bereich Benutzer
- Bereich Metriken
- Bereich Bewertungen
- Bereich Massnahmen
- Tabelle Interne Massnahmen (I) - beziehen sich 1:n auf S
- Tabelle Externe Massnahmen (E) - beziehen sich 1:n auf S
Mit zeitlicher Dimension
------------------------
- Bereich Agenda
Tabelle Agenda (Ag)
Tabelle Aktionen (A) - ein Feld mit Fremdschlüssel auf Agenda
- ein Feld mit Sequenznummer innerhalb der
Agenda
( Die Aktionen sind soweit granular dass sie tatsaechlich sequentiell
abgebildet werden koennen - Parallelisierung von Vorgaengen wird in darüberliegenden (Objekt-)Schichten progammatisch abgebildet. )
Das Problem liegt genau an der Schnittstelle zwischen ( situationsbezogenen ) Massnahmen und ( agendabezogenen ) Aktionen.
Eine Aktion soll in dieser Modellierung _entweder_ eine interne _oder_ eine externe Massnahme beinhalten koennen.
Also : zwei Fremdschlüsselfelder in A - eines für I, eines für E ?
Wie erzwinge ich dann aber dass genau ein FK NULL ist ?
( wg. des entweder-oder)
Da faellt mir nur ein Constraint ein -
das erscheint mir aber strukturell zu schwach.
=> Seht Ihr das anders ? <=
Es gibt oberhalb der Datenbank eine Schicht von Business-Objekten. Dort ist das sehr einfach abzufangen z.B. mit eine abstrakten Basisklasse "Massnahmen" und einer Referenz _auf_ _eine_ Massnahme in der Klasse "Aktionen" die alternativ mit einem I oder E Objekt versorgt wird.
Nur hat die Sache mehrere Haken:
Zur Zeit befindet sich das Projekt in der Phase einer Prototypisierung ( in Python 2.4 ) - es ist geplant das Projekt später sukzessive in C++ zu implementieren.
Deshalb will ich möglichst viel Business-Logik in die Datenbank ziehen.
Deren Struktur ist nämlich z.Zt die einzige echte Konstante die ich erkennen kann.
Auch soll die Wahl der Datenbank mit der das Produkt betrieben wird dem Kunden überlassen werden, deshalb würde ich das gerne so "SQL-rudimentaer" wie möglich abbilden.
Das kann man mit Triggern / SP / Contraints etc formulieren aber das erscheint mir semantisch zu "schwach".
Und ausserdem nur platform - sprich DB - abhängig zu formulieren.
Es gebietet sich doch eigentlich eine strukturelle Lösung, oder ?
=> Kann man die "A besteht entweder aus E oder I" Beziehung strukturell überhaupt in den Griff kriegen ? <=
Entweder versuch ich grad die Quadratur des Kreises oder ich seh den Wald vor lauter Bäumen nicht... ;-)
Vielen Dank fuer's Lesen !
Gruesse
hkl
P.S.:
Prototypisierungsplattform
- Windows XP
- MySQL 5.2 ( InnoDB Engine )
- ggf. ODBC
- Python 2.4
- pywin32 build 205
P.P.S.: Das Ganze faellt vielleicht etwas aus dem Kernthema des Forums, aber die SQL-Thematik erschien mir ein hinreichendes gemeinsames Drittes zu sein.
-
Wie erzwinge ich dann aber dass genau ein FK NULL ist ?
( wg. des entweder-oder)In der Datenzugriffsschicht sorgst Du dafür, dass exakt ein FL NULL ist, in der Datenschicht stellst Du einen datentabellenbezogenen CHECK constraint ein.
Da faellt mir nur ein Constraint ein -
das erscheint mir aber strukturell zu schwach.?
Deshalb will ich möglichst viel Business-Logik in die Datenbank ziehen.
Idealerweise hast Du in der DB zusammen mit den SPs und anderen DB-Objekten ein geschlossenes System, an das es nur ein GUI anzubinden gilt.
Deren Struktur ist nämlich z.Zt die einzige echte Konstante die ich erkennen kann.
:)
Das kann man mit Triggern / SP / Contraints etc formulieren aber das erscheint mir semantisch zu "schwach".
Vorsicht bei Triggern, die anderen Objekte sind lieb und keinesfalls "semantisch schwach".
Und ausserdem nur platform - sprich DB - abhängig zu formulieren.
Es gebietet sich doch eigentlich eine strukturelle Lösung, oder ?Was ist denn eine "unstrukturelle Lösung"?
Entweder versuch ich grad die Quadratur des Kreises oder ich seh den Wald vor lauter Bäumen nicht... ;-)
Bei brainstorming bist Du bei old King^Lully gerade richtig. BTW - wo hast Du die ganze Zeit gesteckt, während unsereins bald sein zehnjähriges Jubiläum hier feiert, verschwindet Euereins nach wenigen Monaten? (Oder wars ein Knastzaufenthalt wg. Datendesignmissbrauch?)
-
Hallo King !
Wie erzwinge ich dann aber dass genau ein FK NULL ist ?
( wg. des entweder-oder)In der Datenzugriffsschicht sorgst Du dafür, dass exakt ein FL NULL ist,
Das versteh ich nicht.
Wie geht das ?in der Datenschicht stellst Du einen datentabellenbezogenen CHECK constraint ein.
Also findest Du die Verwedung eines CHECK CONSTRAINT an der Stelle angemessen ?
[...]
Was ist denn eine "unstrukturelle Lösung"?Strukturell ist die Aufteilung der Daten in Tabellen und deren Beziehungen.
Nach solch einer Lösung suche ich.Gruesse und Dank
hkl
P.S.:
[...]
Bei brainstorming bist Du bei old King^Lully gerade richtig. BTW - »» wo hast Du die ganze Zeit gesteckt, während unsereins bald sein »» zehnjähriges Jubiläum hier feiert, verschwindet Euereins nach
wenigen Monaten? (Oder wars ein Knastzaufenthalt wg.
Datendesignmissbrauch?);-) ROFL
Nee, ich hatte ( mal wieder ) nen NULL - pointer dereferenziert und war im digitalen Nivana gelandet...
War aber nicht so toll!
Deshalb bin ich jetzt erleuchtet und verwende Scriptsprachen.
;-)-
In der Datenzugriffsschicht sorgst Du dafür, dass exakt ein FL NULL ist,
Das versteh ich nicht.
Wie geht das ?Nun, Du hast doch vermutlich für die INSERTs auf Datentabellenebene der CRUD-Philosophie folgend kleine SP-Familien, die zusammen ein grosses Rudel ergeben (und sich liebhaben).
in der Datenschicht stellst Du einen datentabellenbezogenen CHECK constraint ein.
Also findest Du die Verwedung eines CHECK CONSTRAINT an der Stelle angemessen ?
Es gibt keine Alternative. Zudem habe ich nichts gegen CHECK constraints.
-
-
-
Gegeben sei eine abstrakte Klasse A mit zwei konkreten Kindklassen A1 und A2. Eine (Client-)Klasse C referenziert genau ein A; die Referenz ist nie NULL, sondern wird stets mit einem Exemplar von entweder A1 oder A2 versorgt.
Das ist ja ein recht häufig vorkommendes einfaches Muster.
Wie bildet man das auf eine relationale Struktur, also auf SQL Tabellen, ab ?
Gruesse
hkl
-
Mit einem CHECK constraint.
;) -
Hi,
mal n schuss ins Blaue (oder in den Ofen) ;))
Tabelle C
PK
Payload (Nutzdaten)
FK Referenz auf Tabelle A-PKTabelle A
PK
gemeinsame Attribute von A1 und A2Tabelle A1
PK = FK Referenz auf Tabelle A-PK
A1 spezifische Payload DatenTabelle A2
PK = FK Referenz auf Tabelle A-PK
A2 spezifische Payload Daten(Ja, du könntest in A2 und A1 jeweils denselben Key aus A referenzieren, nur warum solltest du das zweimal eintragen -> Da muss deine Geschäftslogik einsetzen und das verhindern)
Wenn du jetzt eine Abfrage machst, kannst du direkt auf ein UNION ALL aus A1 und A2 joinen. Lediglich die Felder müssten entsprechend im Select aufbereitet werden (also SELECT A1.feldA, A1.feldB, NULL ... UNION ALL SELECT NULL, NULL, A2.feldXYZ)
Mit einem CHECK Constraint wie von King Lully erwähnt geht es auch irgendwie.
OO Patterns auf RDBMS'se anzuwenden funktioniert meistens schlecht oder gar nicht.
Vielleicht lese ich mir auch nochmal dein initialposting durch ...
Cheers,
Frank-
Hallo,
Tabelle C
PK
Payload (Nutzdaten)
FK Referenz auf Tabelle A-PKTabelle A
PK
gemeinsame Attribute von A1 und A2Tabelle A1
PK = FK Referenz auf Tabelle A-PK
A1 spezifische Payload DatenTabelle A2
PK = FK Referenz auf Tabelle A-PK
A2 spezifische Payload DatenDas ist eine Möglichkeit.
Weitere gibts z. B. unter http://www.agiledata.org/essays/mappingObjects.html nachzulesen.Grüße
Klaus-
Hallo !
Hallo,
Tabelle C
PK
Payload (Nutzdaten)
FK Referenz auf Tabelle A-PKTabelle A
PK
gemeinsame Attribute von A1 und A2Tabelle A1
PK = FK Referenz auf Tabelle A-PK
A1 spezifische Payload DatenTabelle A2
PK = FK Referenz auf Tabelle A-PK
A2 spezifische Payload DatenDas ist eine Möglichkeit.
Darauf bin ich in der Antwort auf Franks Beitrag eingegangen.
Weitere gibts z. B. unter http://www.agiledata.org/essays/mappingObjects.html nachzulesen.
DAS ist ein tolles Essay !
Vielen Dank fuer den Link !Ich antworte ausführlicher wenn ich den Artikel durchgelesen habe.
Grüße
KlausVielen Dank und Grüsse
Holger
-
-
Hallo!
Hi,
mal n schuss ins Blaue (oder in den Ofen) ;))
Tabelle C
PK
Payload (Nutzdaten)
FK Referenz auf Tabelle A-PKTabelle A
PK
gemeinsame Attribute von A1 und A2Tabelle A1
PK = FK Referenz auf Tabelle A-PK
A1 spezifische Payload DatenTabelle A2
PK = FK Referenz auf Tabelle A-PK
A2 spezifische Payload Daten(Ja, du könntest in A2 und A1 jeweils denselben Key aus A referenzieren, nur warum solltest du das zweimal eintragen -> Da muss deine Geschäftslogik einsetzen und das verhindern)
Danke fuer den Vorschlag und die sehr ausführliche Antwort !
Aber verlagere ich das Problem dadurch nicht nur?
Statt zwei NOT NULL values in einer Tabelle zu verhindern, muss ich jetzt zwei gleiche FK in zwei Tabellen verhindern, oder ?;-(
Wenn du jetzt eine Abfrage machst, kannst du direkt auf ein UNION ALL aus A1 und A2 joinen. Lediglich die Felder müssten entsprechend im Select aufbereitet werden (also SELECT A1.feldA, A1.feldB, NULL ... UNION ALL SELECT NULL, NULL, A2.feldXYZ)
Danke !
Hab auch schon über eine Domain fur die A1,A2 PK nachgedacht und die Beschraenkung auf ein - nicht als FK deklariertes Feld - in C.
Dann könnte die BL die Relation gleichsam "sythetisch" herstellen.Mit einem CHECK Constraint wie von King Lully erwähnt geht es auch irgendwie.
OO Patterns auf RDBMS'se anzuwenden funktioniert meistens schlecht oder gar nicht.
Das ist das was ich hier interessant finde.
Hier brauch ich wirklich mal ( aus diversen Gruenden ) eine direkte Abbildung auf beide "Subsysteme".Ohne irgendeine funktionale Klammer ( entweder Constraint Verletzung abfangen oder wie Du vorschlägst "doppelte" Inserts in der Business-Logik abfangen ) scheint's nicht zu gehen.
Ist vielleicht methodisch aufschlussreich.
Vielleicht lese ich mir auch nochmal dein initialposting durch ...
Cheers,
FrankNochmals vielen Dank !
Grüsse
hkl
-
Tabelle C
PK
Payload (Nutzdaten)
FK Referenz auf Tabelle A-PKTabelle A
PK
gemeinsame Attribute von A1 und A2Tabelle A1
PK = FK Referenz auf Tabelle A-PK
A1 spezifische Payload DatenTabelle A2
PK = FK Referenz auf Tabelle A-PK
A2 spezifische Payload Daten(Ja, du könntest in A2 und A1 jeweils denselben Key aus A referenzieren, nur warum solltest du das zweimal eintragen -> Da muss deine Geschäftslogik einsetzen und das verhindern)
Aber verlagere ich das Problem dadurch nicht nur?Lass die Finger davon, Junge! ;)
-
Tabelle C
PK
Payload (Nutzdaten)
FK Referenz auf Tabelle A-PKTabelle A
PK
gemeinsame Attribute von A1 und A2Tabelle A1
PK = FK Referenz auf Tabelle A-PK
A1 spezifische Payload DatenTabelle A2
PK = FK Referenz auf Tabelle A-PK
A2 spezifische Payload Daten(Ja, du könntest in A2 und A1 jeweils denselben Key aus A referenzieren, nur warum solltest du das zweimal eintragen -> Da muss deine Geschäftslogik einsetzen und das verhindern)
Aber verlagere ich das Problem dadurch nicht nur?Lass die Finger davon, Junge! ;)
Ein unsinniger väterlichen Hinweis ohne fachliche Begründung.
Damit kann ich nichts anfangen.Grüsse
hkl
P.S.: Dein "Junge" bin ich gewiss nicht.
Und versuch bitte in Zukunft auch nicht noch einmal mich so anzusprechen !-
Das war ein Zitat aus einem mehr oder weniger bekannten Film und sollte Dich auf die Hirnrissigkeit des Vorschlags hinweisen. Argumente scheinen mir nur auf gezielte Nachfrage erforderlich.
Wenn ein Spieler Deines Fussballteams ein Eigentor schiesst, dann erklärst Du ihm doch auch nicht (bzw. erst auf Nachfrage ;), warum das schlecht war.
-
-
-
-
-
-
Hi nochmal,
ein paar Kommentare zu Dingen, die mir auf den ersten Blick aufgefallen sind.- Was sind deine "Bereiche"? Logische Funktionseinheiten deiner Anwendung?
- Tabelle Interne Massnahmen (I) - beziehen sich 1:n auf S
- Tabelle Externe Massnahmen (E) - beziehen sich 1:n auf S- warum nicht 1 Tabelle, mit einem Attribut für I und E zur Unterscheidung?
Leider fehlt mir etwas die Vertrautheit mit deiner Materie um schnell mal ein mögliches ERM aus meiner Sicht vorschlagen zu können.
Versuche dich selbst erstmal wieder von der Platformabhängigen Modellierung (OO-Abstraktion, FK und Tabellen und so) zu distanzieren und nochmal von vorn mit den reinen Entitäten (Was ist eine Massnahme, was ist eine Situation, was hängen welche Entitäten zusammen).
Hast du für dein Projekt auch eine praktische Anwendung (Auftrag, Muster-Nachentwicklung)?
Cheers, Frank
-
Hi nochmal,
ein paar Kommentare zu Dingen, die mir auf den ersten Blick aufgefallen sind.- Was sind deine "Bereiche"? Logische Funktionseinheiten deiner Anwendung?
Du kennst also den Begriff Bereich nicht im Zusammenhang mit Datenmodellierung?
Bereiche sind Mengen von Tabellen die in einem engen thematischen
Bezug zueinander stehen. ( z.B "Benutzer" beinhaltet Tabellen wie Personen, Adressen, Kontakte etc.. )Schau Dir dazu vielleicht nochmal meine Auflistung in meinem Ausgangsposting an.
- Tabelle Interne Massnahmen (I) - beziehen sich 1:n auf S
- Tabelle Externe Massnahmen (E) - beziehen sich 1:n auf S- warum nicht 1 Tabelle, mit einem Attribut für I und E zur Unterscheidung?
Die Tabellen werden jeweils von grossen Mengen M1, M2 weiterer Tabellen jeweils 1:n referenziert.
Die beiden Mengen M1, M2 sind nahezu disjunkt.Leider fehlt mir etwas die Vertrautheit mit deiner Materie um schnell mal ein mögliches ERM aus meiner Sicht vorschlagen zu können.
Das ist auch nicht notwendig. Das ist meine Aufgabe.
Versuche dich selbst erstmal wieder von der Platformabhängigen Modellierung (OO-Abstraktion, FK und Tabellen und so) zu distanzieren und nochmal von vorn mit den reinen Entitäten (Was ist eine Massnahme, was ist eine Situation, was hängen welche Entitäten zusammen).
Danke, aber erstens weiss ich wie man Software entwickelt ;-), zwitens haben wir bereits einen Evolutionszyklus samt Refactoring mit dem Modell durchlaufen und drittens wird das nichts bringen.
Diese Tabellen ( und Klassen ) braucht das Modell ganz einfach.
Hast du für dein Projekt auch eine praktische Anwendung (Auftrag, Muster-Nachentwicklung)?
Ja, viele. Un die braeuchtest Du auch um die Modelliergung zu verstehen.
Das führt an dieser Stelle zu weit.Cheers, Frank
-
Hallo,
du hörst dich ziemlich "angepisst" an. Den Grund dafür kann ich nicht
wirklich erlesen. Die Antwortenden in diesem Thread versuchen dir zu
helfen, u.a. indem sie Möglichkeiten suchen, sich in dein Problem
hineinversetzen zu können. Natürlich kann Hilfe auch subjektiv als zu
"väterlich" empfunden werden, aber da muss man nicht so angekratzt
reagieren.Danke, aber erstens weiss ich wie man Software entwickelt ;-), zwitens haben wir bereits einen Evolutionszyklus samt Refactoring mit dem Modell durchlaufen und drittens wird das nichts bringen.
Du kennst also den Begriff Bereich nicht im Zusammenhang mit Datenmodellierung?Disqualifiziert mich das als Helfenden? Schade, da kann ich nix gegen machen.
Sorry, Ciao,
Frank-
Du kennst also den Begriff Bereich nicht im Zusammenhang mit Datenmodellierung?
Disqualifiziert mich das als Helfenden? Schade, da kann ich nix gegen machen.
Den Begriff gibts auch nicht. ;)
-
Hi Ludger,
Den Begriff gibts auch nicht. ;)
In seiner Welt wohl schon. In seiner Welt gibt es auch andere Probleme. :)
Ciao, so long,
Frank-
Hi Ludger,
Den Begriff gibts auch nicht. ;)
In seiner Welt wohl schon. In seiner Welt gibt es auch andere Probleme. :)
Und jetzt definier bitte mal welche der drei betieligten subjektiven Welten die objektiv "richtige" ist.
;-)
Grüsse
Holger
Ciao, so long,
Frank-
Hi,
ich verstehe deine Frage nicht.
Je weiter dieser Thread fortschreitet, desto mehr verschwimmt deine Problematik (vorallem aufgrund deiner Antworten). Deshalb noch mal ein Recap auf Basis deiner letzten Antworten.
Bereiche sind Mengen von Tabellen die in einem engen thematischen
Bezug zueinander stehen. ( z.B "Benutzer" beinhaltet Tabellen wie Personen, Adressen, Kontakte etc.. )
Schau Dir dazu vielleicht nochmal meine Auflistung in meinem Ausgangsposting an.Okay, aber das hat nichts mit deinem OO-in-RDBMS-Modellierungsproblem zu tun. Auch wenn ich mir das noch 100 mal anschaue, es ändert nix. Aber dank deiner Antwort haben wir jetzt dieselbe Vorstellung von "Bereich".
- Tabelle Interne Massnahmen (I) - beziehen sich 1:n auf S
- Tabelle Externe Massnahmen (E) - beziehen sich 1:n auf S- warum nicht 1 Tabelle, mit einem Attribut für I und E zur Unterscheidung?
Die Tabellen werden jeweils von grossen Mengen M1, M2 weiterer Tabellen jeweils 1:n referenziert.
Die beiden Mengen M1, M2 sind nahezu disjunkt.Ja und? Wo ist der Zusammenhang zwischen Menge M1, M2, deren potentieller Schnittmenge und der Relation zu "Massnahmen"? Oder sind M1 die internen Massnahmen und M2 die externen? Ich dachte, die heissen I und E. Und interessant wäre, wieviel Gemeinsamkeiten I und E haben.
Diese deine Antwort war ein sehr gutes Beispiel dafür, wie du die Problematik noch weiter verwirren und verschwimmen lässt.
Leider fehlt mir etwas die Vertrautheit mit deiner Materie um schnell mal ein mögliches ERM aus meiner Sicht vorschlagen zu können.
Das ist auch nicht notwendig. Das ist meine Aufgabe.
Aber du brauchst/suchst/willst Hilfe, oder doch nicht?
Danke, aber erstens weiss ich wie man Software entwickelt ;-), zwitens haben wir bereits einen Evolutionszyklus samt Refactoring mit dem Modell durchlaufen und drittens wird das nichts bringen.
Diese Tabellen ( und Klassen ) braucht das Modell ganz einfach.Aber du brauchst/suchst/willst Hilfe, oder doch nicht?
Und Ignoranz ist übrigens keine Tugend.Ja, viele. Un die braeuchtest Du auch um die Modelliergung zu verstehen.
Das führt an dieser Stelle zu weit.Aber das, was du lieferst an Problembeschreibung, macht es nicht gerade leicht, dir Hilfe bei der Modellierung zu bieten. Du kennst das Sprichwort "Wie man in den Wald hineinruft, so schallt es heraus."?
In diesem Thread hast du schon mehrere rein technische Ansätze (Check Constraints, Tabellenschemata) gesehen. Ich bleibe jedoch bei meiner Meinung, dass ihr/du mindestens eine grundsätzliche konzeptionelle Schwäche / Fehler im Modell habt und mein Rat: Back to field 1!
Hast du jetzt eigentlich noch konkrete Fragen?
So long, Frank
-
Hi,
ich verstehe deine Frage nicht.
Das stimmt offenabar.
Das musst Du auch nicht unbedingt leisten können.
Danke soweit![...]
Grüsse
hkl
-
ich verstehe deine Frage nicht.
Das stimmt offenabar.
Das musst Du auch nicht unbedingt leisten können.
Danke soweit!Uns stört an solchen Kommunikationsdesastern eigentlich nichts.
Allerdings ist Unser persönlicher Eindruck bzgl. der Beteiligten recht positiv, so dass Uns dieses Ergebnis in diesem speziellen Fall schon ein wenig stört.Zu Dir also, Unser Freund, Du neigst zum Verkomplizieren von Sachverhalten, einer sportlich/aggressiven Herangehensweise (was nicht schlecht ist) und zu open end brainstorming.
Bleib doch einfach locker, hier nervt Dich keiner absichtlich (bzw. unverdientermassen ;). Störer dagegen gibts hier zuhauf, reagiere Dich da ab. Machen Wir ja auch. ;)-
Zu Dir also,
UnserPlural? Schon wieder von den Keksen genascht?
Oder biste grad gedanklich verschmolzen?Freund, Du neigst zum Verkomplizieren von Sachverhalten, einer sportlich/aggressiven Herangehensweise (was nicht schlecht ist) und zu open end brainstorming.
Whatever that might be...
Bleib doch einfach locker, hier nervt Dich keiner absichtlich
Kennst Du/Ihr eigentlich den Sputnik-Cocktail?
1/2 Whiskey 1/2 Wasser
halb austrinken
mit Whiskey auffüllen
halb austrinken
mit Whiskey auffüllen
...hoer(s)t Du/Ihr das "Piep-Piep-Piep" aus der Umlaufbahn?
Bestimmt...Also : reiss Dich von T'Pol los oder Ihr Euch voneinander, gib ihr Kekse mit und beam sie rüber.
Schwebe lang und in Frieden !
hkl
-
-
-
-
-
-
Hallo,
du hörst dich ziemlich "angepisst" an. Den Grund dafür kann ich nicht wirklich erlesen.
Eben. Bin ich naemlich gar nicht. Ich weiss nicht wieso Du das in meine Antwort hineininterpretierst.
Die Antwortenden in diesem Thread versuchen dir zu
helfen, u.a. indem sie Möglichkeiten suchen, sich in dein Problem
hineinversetzen zu können. Natürlich kann Hilfe auch subjektiv als zu "väterlich"Steht das in meiner Antwort?
empfunden werden, aber da muss man nicht so angekratzt
reagieren.Angekratzt erscheinst mir eher Du.
Danke, aber erstens weiss ich wie man Software entwickelt ;-), zwitens haben wir bereits einen Evolutionszyklus samt Refactoring mit dem Modell durchlaufen und drittens wird das nichts bringen.
Du kennst also den Begriff Bereich nicht im Zusammenhang mit Datenmodellierung?Disqualifiziert mich das als Helfenden?
Nein. Habe ich das geschrieben ?
Schade, da kann ich nix gegen machen.
Sorry, Ciao,
FrankGrüsse
Holger
-