Modellierung Tennis Forderungsbaum

Re(5): Modellierung Tennis Forderungsbaum

Linux_Sucks — Mon, 27 Nov 2006 15:59:57 GMT

HeyHey...

Best-Practice-Methoden sind nicht ohne Grund BestPractice...

Und wenn man praktisch "gratis" (also ohne viel Aufwand) alle möglichen interessanten Statistiken rauskriegen kann, würde ich das nutzen...

Und ja, ich bin ein Fan von Constraints in der DB... Insbesondere bei lange laufenden DBs lerne ich das immer wieder schätzen...

Abschließend:
Wenn man das nicht einmal bei kleinen Sachen hinbekommt, wäre es bei größeren ja inpraktikabel... Und ich würde das echt als "Lernmuster" sehen...

Re(4): Modellierung Tennis Forderungsbaum

Robert Craven — Mon, 27 Nov 2006 15:49:41 GMT

Ich find dich immer wieder amüsant. "Mit Kanonen auf Spatzen schiessen", reicht bei dir gar nicht. Da müsste man schon sagen, "mit Kanonen auf Elefanten schiessen", obwohl man eigentlich auf Spatzenjagd ist.

Re(4): Modellierung Tennis Forderungsbaum

SchusterHarry — Mon, 27 Nov 2006 15:35:27 GMT

hoi,

ich hab das nicht brutal gemeint, auch wars keine Kritik an ihm da ich nicht beurteilen kann was schwer ist und was nicht ....das Thema um das es hier geht ist für mich "Ausland" + do kenn i mi ned aus

Meine Aussage war eher allgemein gemeint und nicht auf die Person bezogen

Re: Uuuups...

ruprecht69 — Mon, 27 Nov 2006 15:25:01 GMT

Naja .. die SW-Entwickler heutzutage sind auch nicht mehr das, was sie mal waren .

Uuuups...

Linux_Sucks — Mon, 27 Nov 2006 12:17:24 GMT

Ich sehe erst jetzt, daß er ja professioneller SW-Entwickler ist (aus einem anderen Thread)... Sorry.

Dann verstehe ich allerdings seine Fragen erst recht nicht... Echt nicht.
Ist das ein Witz von ihm oder wie ?

Re(5): Modellierung Tennis Forderungsbaum

Linux_Sucks — Mon, 27 Nov 2006 11:58:22 GMT

Glaube ich nicht... Auch wenn ich früher sowas unterschrieben hätte.

Tatsächlich kommt immer irgendwas dazu... Und wenn du ein sauberes Design hast, bleibt es schön wartbar und änderbar.... Eine Software, die nicht modifiziert wird, ist IMHO eine tote Software.

Abgesehen davon sind bei einer Pimperl-Anforderung natürlich auch nur Pimperl-Diagramme vonnöten... Auch nur wenige Use Cases, ...

Ich würde es echt so aufziehen.
Erstens ist Zeit in Planung investieren besser investiert als nachher "umschreiben" (Also zumindest ich bin meinen "Das machma ganz schnell"-Ansätzen praktisch immer langsamer gefahren als nach gutem Design), Zweitens ist das ein schönes, kleines, praxisbezogenes Übungsbeispiel...

Abschließend:
Wenn seine SW in seinem Club oder wo-auch-immer läuft, kann es zusätzliche Effekte geben. zB In 2-3 Jahren:
1.) will der Club eine Änderung wie zB Mitgliederabrechnungen dazuwerfen, ...und/oder
2.) ein anderer Club will was ähnliches .... und/oder
3.) eine andere Sportgattung will was ähnliches...

In jedem dieser Fälle (also wenn man sich in 2 Jahren mit 2 Jahre altem Code rumschlägt) profitiert man extremst von sauberer Doku... Selbst bei Pimpal-Gschichten .

Re(4): Modellierung Tennis Forderungsbaum

ruprecht69 — Mon, 27 Nov 2006 11:53:00 GMT

Was für so eine Pimperlanforderung ja wohl ein bissi überdimensioniert sein dürfte.

Re: Modellierung Tennis Forderungsbaum

Linux_Sucks — Mon, 27 Nov 2006 10:48:49 GMT

Bitte liefer mal deine Diagrammentwürfe...

http://forum.geizhals.at/t460371,3799731.html#3799731

Re(3): Modellierung Tennis Forderungsbaum

Linux_Sucks — Mon, 27 Nov 2006 10:48:26 GMT

Hey Harry....

Sei nicht wieder so brutal... Erstens hat jeder mal angefangen, zweitens kommt er vielleicht eh auf eine gute Lösung...

Lassen wir uns einfach mal sein Klassen- und Sequenzdiagramm ansehen und schauen dann weiter...

Re(3): Modellierung Tennis Forderungsbaum

Linux_Sucks — Mon, 27 Nov 2006 09:14:13 GMT

Aufgelöste N:M-Beziehung...

Ach ja, die Position ist mir unklar... Die ist ja veränderlich, oder ? Also könnte man eine extra Positionstabelle bauen, a la
Position:
id int4 primary key,
Spieler int4 references spieler(id) not null,
ab date not null,
aktuell boolean not null default 'f',
position int4)

Dazu 2 Partielle unique indizes (damit aktuelle Positionen unique sind bzw. ein Spieler aktuell nur eine Pos haben kann):
CREATE UNIQUE INDEX idx_position_pos on position(position) where aktuell;
CREATE UNIQUE INDEX idx_position_spieler on position(Spieler) where aktuell;

Und dann halt noch einen INSERT/UPDATE/DELETE-Trigger, der aktuell immer beim höchsten Datum auf 't' setzt..

Das ist zwar nicht super-performant, aber da ein Positionswechsel eh nicht so oft passiert, macht es wohl nix. Ich vermute zwar schon, daß ein Positionstausch dann durchaus so 1/10 sec dauern kann - aber das wäre mir wohl die Sicherheit wert.

Alternativ könnte man sich - anstelle der 2 Indizes - durchaus auch einen DEFERRABLE CHECK CONSTRAINT vorstellen... Das würde ich als Geschmackssache beurteilen. Letzteres hätte den Vorteil, daß man bequemer in einer Transaktion updaten kann, die Indizes hingegen wirst so oder so eh gerne für deine Auswertungen brauchen.

Re(11): Modellierung Tennis Forderungsbaum

leave_my_name_out — Sun, 26 Nov 2006 22:08:59 GMT

keine frage aber es kann manchmal dauern, bis das dann durchgesickert is

Re(10): Modellierung Tennis Forderungsbaum

SchusterHarry — Sun, 26 Nov 2006 22:04:07 GMT

grundsätzlich alles können müsst

und dann hat ein GUTER EDV Hawara zu sagen "tut mir leider aber niemand kann alles wissen"

Re(9): Modellierung Tennis Forderungsbaum

leave_my_name_out — Sun, 26 Nov 2006 21:59:16 GMT

jeder meint ALLES zu können und sieht nicht ein das das nicht geht

naja, und dann gibt's noch die die glauben, dass jeder edv-fuzzi grundsätzlich alles können müsst eh alles des selbe, des computerzeugs

Re(3): Modellierung Tennis Forderungsbaum

HuberSepp — Sun, 26 Nov 2006 16:59:41 GMT

2 x 1:N

Re(9): Modellierung Tennis Forderungsbaum

Dr. Watson — Sun, 26 Nov 2006 10:54:32 GMT

Und so hat der Tischler einen Cisco 19" Switch verkauft bekommen, mit 32
Anschlüssen (glaub ich) .,....für ganze 4 Pcs...der Dienstleister meinte das
ein kleiner das Netzwerk nicht "versorgen"könnte ..*gg*

Es geht auch in die andere Richtung...ich kenn ne Firma, da wurde ein uralter 24-Port Ethernet Hub (immerhin ein 10/100er) in einer Schublade "installiert, und natürlich teuer verrechnet.
Bei einem Server und einem Client ging das noch halbwegs gut, mittlerweile sinds 10 Clients, und die Collision Led leuchtet im Dauerzustand, während das Ding in der Schublade beinahe abfackelt.

Wie du schon sagst...unpackbar was man da oft vorfindet.

Re(8): Modellierung Tennis Forderungsbaum

SchusterHarry — Sun, 26 Nov 2006 10:49:00 GMT

dumm nur, dass sich eigentlich jeder einen gewerbeschein lösen kann

tjo so ists wohl...

ne, im ernst, den kunden ist weniger der vorwurf zu machen als den vielen
"jaja, mach ich schon"`s - die sich dann spätestens beim kunden in foren
einloggen und um hilfe schreien...

seh ich so wie du...

Re(8): Modellierung Tennis Forderungsbaum

SchusterHarry — Sun, 26 Nov 2006 10:49:00 GMT

dumm nur, dass sich eigentlich jeder einen gewerbeschein lösen kann

tjo so ists wohl...

ne, im ernst, den kunden ist weniger der vorwurf zu machen als den vielen
"jaja, mach ich schon"`s - die sich dann spätestens beim kunden in foren
einloggen und um hilfe schreien...

seh ich so wie du...wobei ichs auch so seh: jeder meint ALLES zu können und sieht nicht ein das das nicht geht

Wenn ich für jemand was machen soll schau ichs mir an, trau ichs mir nicht zu lass ich es sein und das kam durchaus schon mehrmals vor..wieso das andere nicht schaffen sich einzugestehen das eben nicht alles für einen Mann machbar ist weis ich nicht

Re(8): Modellierung Tennis Forderungsbaum

SchusterHarry — Sun, 26 Nov 2006 10:48:21 GMT

Da würd ich mir als Geschäftsführer so schnell wie möglich eine interne
EDV-Abteilung schaffen, bevor ich auch nur irgendwie so einen Dealer
heranziehe.

najo zb wär das für den Augenarzt oder den Tischler die ich betreue nicht möglich.....bei weniger als 10 Mitarbeitern wär das zu teuer

Und so hat der Tischler einen Cisco 19" Switch verkauft bekommen, mit 32 Anschlüssen (glaub ich) .,....für ganze 4 Pcs...der Dienstleister meinte das ein kleiner das Netzwerk nicht "versorgen"könnte ..*gg*

und der Augenarzt hat ein ungesichertes WLAN bekommen..............unpackbar sowas wenn man bedenkt das da Kundendaten in Bezug auf Gesundheit unterwegs sind..sicher nix was andere was aneght

Re(7): Modellierung Tennis Forderungsbaum

hariw — Sun, 26 Nov 2006 10:44:22 GMT

hi,

jupp, dumm nur, dass sich eigentlich jeder einen gewerbeschein lösen kann

ne, im ernst, den kunden ist weniger der vorwurf zu machen als den vielen "jaja, mach ich schon"`s - die sich dann spätestens beim kunden in foren einloggen und um hilfe schreien...

lg,
hariw

Re(7): Modellierung Tennis Forderungsbaum

Dr. Watson — Sun, 26 Nov 2006 10:44:06 GMT

Stimmt, das kann ich gut Nachvollziehen.
Hab da vor kurzem erst ein paar Geschichten über unseren lokalen EDV-Dealer gehört, da stellts einem die Haare auf...

Das Problem ist, dass die kleinen EDV Dienstleister selten kompetent sind, und was das ganze noch schlimmer macht: Weil sie meist ein Monopol in ihrer Umgebung haben, sind die Firmen ohne eigenständige EDV-Abteilung auch noch auf diese Dienstleister angewiesen.

Da würd ich mir als Geschäftsführer so schnell wie möglich eine interne EDV-Abteilung schaffen, bevor ich auch nur irgendwie so einen Dealer heranziehe.

Re(6): Modellierung Tennis Forderungsbaum

SchusterHarry — Sun, 26 Nov 2006 10:38:58 GMT

Das wird das Problem sein.

siehste..das sollte man nie vergessen wenn man sich wundert das Leut nur EDV Pfusch haben..hab selber ne kleine Firma , die waren bei allen örtlichen EDV Dealern und Dienstleistern...also durchaus auch bereit richtig Geld zu zahlen aber was sich da abgespielt hast kannst dir nicht vorstellen

Teilweise sind die Leut die einfach nur einen guten suchen echt arme Schweine weils eben nicht wissen wie man gut und wneiger gut unterscheiden kann und du den Leuten alles erzählen kannst weils jo keine Ahnung haben

Re(5): Modellierung Tennis Forderungsbaum

Dr. Watson — Sun, 26 Nov 2006 10:34:53 GMT

Das wird das Problem sein.

Re(4): Modellierung Tennis Forderungsbaum

SchusterHarry — Sun, 26 Nov 2006 10:31:30 GMT

Tolle Einstellung...

woher bitte soll ein 0815 Vereinsobmann wissen wer "gut" ist und wer nicht?

Re(2): Modellierung Tennis Forderungsbaum

S p o r t f r e u n d — Sun, 26 Nov 2006 10:30:55 GMT

der join von Ergebnisse.Forderer = Spieler.Schlüssel ist mir klar. Nur um welchen Beziehungstyp handelt es sich zwischen den beiden Tabellen? N:M?

Re(3): Modellierung Tennis Forderungsbaum

Dr. Watson — Sun, 26 Nov 2006 10:28:50 GMT

Tolle Einstellung...

Hätte sich der Verein gleich ums doppelte Geld einen ordentlichen Entwickler geholt, würde Punkt 3) gleich von Anfang an erfüllt sein.

Re(2): Modellierung Tennis Forderungsbaum

SchusterHarry — Sun, 26 Nov 2006 10:24:54 GMT

Der DB-Optimierer verdient sich dann wieder eine goldene Nase, weil er die
Performance um das XX-fache steigern konnte, und eigentlich nur ein paar
Indizes gesetzt hat.

najo dann ists eh gut das es Leut gibt die das Zeug zuerst falsch machen, so haben jo alle was davon

der der es falsch macht kassiert
der der es optimiert kassiert
und der Verein hat ein Ding das im Endeffekt hinhaut

Alle sind happy und man sollte froh sein das Leut was machen das nicht auf Anhieb hinhaut denn sonst wären Datenbankoptimierer jo alle arbeitelos

Re: Modellierung Tennis Forderungsbaum

Dr. Watson — Sun, 26 Nov 2006 10:18:58 GMT

Das ist doch simpel bis zum geht nicht mehr....die Felder Forderer und Geforderter beinhalten jeweils den Schlüssel des Spielers, der natürlich eindeutig sein muss.

Lässt sich dann mit ganz einfach zusammen joinen, per join von Ergebnisse.Forderer = Spieler.Schlüssel.

Ich sag ja immer, dass man ein gewisses Wissen vorweisen sollte, bevor man sich an irgendwelche Projekte / Aufträge macht, aber scheinbar haben die Leute nur noch ein $ in den Augen, wenn sie um Hilfe gefragt werden.

Am Ende haben wir dann wieder Skripte, die nicht mal gegen SQL-Injections sicher sind, und Datenbanken, in denen es keinen einzigen Index gibt.
Der DB-Optimierer verdient sich dann wieder eine goldene Nase, weil er die Performance um das XX-fache steigern konnte, und eigentlich nur ein paar Indizes gesetzt hat.

Re(3): Modellierung Tennis Forderungsbaum

Pervasive — Sun, 26 Nov 2006 09:24:24 GMT

Ich glaub Du schießt mit Kanonen auf Spatzen...

Re(2): Modellierung Tennis Forderungsbaum

S p o r t f r e u n d — Sun, 26 Nov 2006 09:23:08 GMT

ich wollt nur sichergehen ob meine lösung so wie ich sie machen würde auch richtig ist!

Re: Modellierung Tennis Forderungsbaum

Pervasive — Sun, 26 Nov 2006 09:20:29 GMT

Also wenn Du nicht einmal die einfachsten logischen Aufgaben SELBST erledigen kannst...solltest vielleicht das ganze Projekt lassen...

Modellierung Tennis Forderungsbaum

S p o r t f r e u n d — Sun, 26 Nov 2006 08:50:46 GMT

Ich bin dabei für einen Tennisverein einen Forderungsbaum zu programmieren. Die Tabelle Spieler die ich in der Datenbank brauche ist klar, jedoch brauch ich noch eine 2. Tabelle Ergebnisse, um die Resultate der Forderungen zu speichern.

Jedoch weiß ich nicht genau wie ich die Beziehungen der beiden Tabellen in meiner MySQL DB abbilden soll...

Welche Beziehung würdet ihr zwischen Spieler und Forderung sehen?

Tabelle Spieler:
Schlüssel = Laufende Nummer
Nachname
Vorname
Position
Username
passwort

Tabelle Ergebnisse
Schlüssel = Laufende Nummer
Datum
Forderer
Geforderter
Ergebnis
gespielt (Kennzeichen ob das Spiel bereits gespielt wurde)