Normalisierung: brauche Tipp...

Normalisierung: brauche Tipp...

am 02.07.2007 14:12:29 von i.steinhardt

Moin, Moin!

ich hänge in einer "Gedankenschleife" fest und brauche einen Tipp zu
Lösung meines Problems...

Die Fakten:
1) Tabelle Stammdaten
id | nr | bez ...

2) Tabelle Bezirke
id | bezirksname | bezirksummer | update_datetime | update_name ...

In den Stammdaten werden verschiedene Stammdaten abgelegt, das
besondere: bei jeder Änderung wird ein neuer Datensatz angelegt, weil
die "Historie" nachvollziehbar sein muss.

Es wäre jetzt zur Speicherung eines Bezirkes in den Stammdaten
einfach, in "bez" die id aus Tabelle bezirke zu speichern. So kann
auch bei geänderten Bezirksnamen der damalige Stand wieder erzeugt
werden.

ABER
wie mache ich dies, wenn nicht nur ein Bezirk sondern mehrere Bezirke
in dem Stammdatenfeld "bez" gespeichert werden sollen.

Gruss Ingolf

Re: Normalisierung: brauche Tipp...

am 02.07.2007 14:46:53 von Andreas Haase

i.steinhardt@web.de schrieb:
> ABER
> wie mache ich dies, wenn nicht nur ein Bezirk sondern mehrere Bezirke
> in dem Stammdatenfeld "bez" gespeichert werden sollen.

M:N-Beziehung ueber eine Verknuefpungstabelle, in der vermerkt wird, ob
die Beziehung aktuell oder archiviert ist?

Tschau,
Andreas

Re: Normalisierung: brauche Tipp...

am 02.07.2007 14:54:45 von Gregor Kofler

i.steinhardt@web.de meinte:

> ABER
> wie mache ich dies, wenn nicht nur ein Bezirk sondern mehrere Bezirke
> in dem Stammdatenfeld "bez" gespeichert werden sollen.

Mit einer m:n-Beziehung, die sich durch eine zusätzliche Tabelle in
deiner DB manifestiert und 2 Felder hat: stammdatenID und bezirkeID; den
PK kann man aus diesen beiden Feldern zusammensetzen.

Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Normalisierung: brauche Tipp...

am 02.07.2007 20:51:56 von i.steinhardt

> Mit einer m:n-Beziehung, die sich durch eine zusätzliche Tabelle in
> deiner DB manifestiert und 2 Felder hat: stammdatenID und bezirkeID; den
> PK kann man aus diesen beiden Feldern zusammensetzen.

PK??? Abkürzung für...

Re: Normalisierung: brauche Tipp...

am 02.07.2007 21:00:42 von Andreas Kretschmer

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Normalisierung: brauche Tipp...

am 02.07.2007 21:13:51 von i.steinhardt

>
> M:N-Beziehung ueber eine Verknuefpungstabelle, in der vermerkt wird, ob
> die Beziehung aktuell oder archiviert ist?

An eine Verknüpfungstabelle habe ich auch gedacht - meinte, es gäbe
eine "elegantere" Lösung des Problems...

... dennoch: Verknüpfungstabelle

In der Tabelle "Bezirke" ist bekannt, welche Einträge zum jetzigen
Zeitpunkt auswählbar sind - vergangene Bezirke bzw. deren
Bezeichnungen werden ja durch die Vernüpfung mit der ID korrekt
angezeigt. Wie sollte die Verknüpfungstabelle aussehen, wenn mehrere
Bezirke als "UND" zugelassen sind?
zB.

1.) Tabelle Stammdaten (mit "bezirksnummer" in Spalte "bez" !!!)
id | nr | bez ...
1 | 234 | 1,4,5
2 | 387 | 1,6,7
3 | 390 | 6,7

2) Tabelle Bezirke
id | bezirksname | bezirksummer | update_datetime | update_name ...
1 | bezA | 1
2 | bezD | 4
3 | bez E | 5
4 | bezF | 6
5 | bezG | 7

=3D> Verknüpfung??
stammdaten_nr | bezirk_id
234 | 1
234 | 2
234 | 3
387 | 1
387 | 4
387 | 5
390 | 4
390 | 5

Die Sache ist in sofern "unelegant", da ich bei jeder Veränderung der
Stammdaten eine neue Zeile erzeuge - ergo, wenn ich an den
Bezirksdaten in den Stammdatensätzen etwas ändere (z.B. für
stammdaten_nr 234 einen Bezirk Lösche und einen weiteren Hinzufüge)
muss ich die gesammte Verknüpfungstabelle mit den Daten zu
stammdaten_nr 234 durchforsten inkl delete + insert...


ODER???!?!?

gruss ingolf

Re: Normalisierung: brauche Tipp...

am 02.07.2007 22:58:48 von Gregor Kofler

i.steinhardt@web.de meinte:

> Die Sache ist in sofern "unelegant", da ich bei jeder Veränderung der
> Stammdaten eine neue Zeile erzeuge - ergo, wenn ich an den
> Bezirksdaten in den Stammdatensätzen etwas ändere (z.B. für
> stammdaten_nr 234 einen Bezirk Lösche und einen weiteren Hinzufüge)
> muss ich die gesammte Verknüpfungstabelle mit den Daten zu
> stammdaten_nr 234 durchforsten inkl delete + insert...
>
>
> ODER???!?!?

Nein. Wenn sich an den Stammdaten oder Bezirken was ändert, dann wird
das in den jeweiligen Tabellen geändert. Eine Änderung. Sollte ein
Datensatz rausfliegen (und somit elternlose Kinder in der
Normalisierungstabelle entstehen), dann wird das durch die korrekte Wahl
der Speicherengine (InnoDB) und einem passend eingerichteten FK (Foreign
Key) von der DB automatisch erledigt. Und über die "vielen Zeilen" musst
du dir auch keinen Kopf machen - Datenbanksysteme sind darauf spezialisiert.

Du solltest dir mal einige Grundlagen über relationale Datenbanken
aneignen.

Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Normalisierung: brauche Tipp...

am 03.07.2007 10:30:48 von i.steinhardt

>
> Nein. Wenn sich an den Stammdaten oder Bezirken was ändert, dann wird
> das in den jeweiligen Tabellen geändert. Eine Änderung. Sollte ein
> Datensatz rausfliegen (und somit elternlose Kinder in der
> Normalisierungstabelle entstehen), dann wird das durch die korrekte Wahl
> der Speicherengine (InnoDB) und einem passend eingerichteten FK (Foreign
> Key) von der DB automatisch erledigt. Und über die "vielen Zeilen" musst
> du dir auch keinen Kopf machen - Datenbanksysteme sind darauf spezialisie=
rt.
>
> Du solltest dir mal einige Grundlagen über relationale Datenbanken
> aneignen.
>
... wo hören Grundlagen auf und fängt "Wissen" an... ;-)

FKs sind eine feine Sache - aber wie läuft die Sache mit "Nativ-MySQL"
ohne FK?

... vorab: Danke für die Antworten!

gruss ingolf

Re: Normalisierung: brauche Tipp...

am 03.07.2007 11:48:47 von Andreas Scherbaum

Hallo,

i.steinhardt@web.de wrote:
>>

Dein Quoting ist ... unzulänglich. Du hast gelöscht, wer das von
dir zitierte geschrieben hat.


>> Du solltest dir mal einige Grundlagen über relationale Datenbanken
>> aneignen.
>>
> ... wo hören Grundlagen auf und fängt "Wissen" an... ;-)

Letzteres beinhaltet ersteres.


> FKs sind eine feine Sache - aber wie läuft die Sache mit "Nativ-MySQL"
> ohne FK?

"Nativ-MySQL", wie du es so schön nennst, bringt InnoDB mit. Man muss
das nur nutzen (wollen). Wenn du keine FK brauchst, suchst du eigentlich
keine Datenbank sondern ein Datengrab. Aber dann können die Daten auch
nicht so wichtig sein.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Normalisierung: brauche Tipp...

am 03.07.2007 13:53:31 von i.steinhardt

On 3 Jul., 11:48, Andreas Scherbaum wrote:

> Dein Quoting ist ... unzulänglich. Du hast gelöscht, wer das von
> dir zitierte geschrieben hat.

ok. habs gesehen...

>
> > FKs sind eine feine Sache - aber wie läuft die Sache mit "Nativ-MySQL"
> > ohne FK?
>
> "Nativ-MySQL", wie du es so schön nennst, bringt InnoDB mit. Man muss
> das nur nutzen (wollen). Wenn du keine FK brauchst, suchst du eigentlich
> keine Datenbank sondern ein Datengrab. Aber dann können die Daten auch
> nicht so wichtig sein.
>

in den MySQL-Büchern (ggf. schon etwas angestaubt) ist zu lesen: "das
Fehlen von FKs kann verschmerzt werden, da diese mit entsprechender
Programmlogik ersetzt werden können..."

Ich habe mal bei einem meiner Provider per PHPMyAdmin geguckt, was für
Typen angeboten werden:
Default engine as of MySQL 3.23 with great performance: MyISAM
Hash based, stored in memory, useful for temporary tables: MEMORY
Archive storage engine: ARCHIVE
CSV storage engine: CSV
Federated MySQL storage engine: FEDERATED
Collection of identical MyISAM tables: MRG_MYISAM

von InnoDB nix zu sehen...

Gruss Ingolf

Re: Normalisierung: brauche Tipp...

am 03.07.2007 14:10:34 von Gregor Kofler

i.steinhardt@web.de meinte:

> in den MySQL-Büchern (ggf. schon etwas angestaubt) ist zu lesen: "das
> Fehlen von FKs kann verschmerzt werden, da diese mit entsprechender
> Programmlogik ersetzt werden können..."

Es empfiehlt sich aktuelle Literatur und nicht so ein Sch...ss.

Etwa "MySQL 5" von Michael Kofler.

> Ich habe mal bei einem meiner Provider per PHPMyAdmin geguckt, was für
> Typen angeboten werden:
> Default engine as of MySQL 3.23 with great performance: MyISAM

[snip]
Such dir einen anderen Provider. Zudem: Auch MySQL 3.23 kannte schon
InnoDB. Mittlerweile gab es übrigens MySQL 4.0 (stable seit über 4
Jahren), 4.1 und 5.0. 5.1 und höher sind in Arbeit.

http://de.wikipedia.org/wiki/Mysql#Geschichte

Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Normalisierung: brauche Tipp...

am 03.07.2007 14:38:00 von Andreas Kretschmer

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Normalisierung: brauche Tipp...

am 03.07.2007 14:47:02 von Gregor Kofler

Andreas Kretschmer meinte:

> Ja. Das ist eines der Hauptprobleme von MySQL: fehlende Features wurden
> als Plus der DB verkauft. Besonders schön z.B. hier:

Es *war* wohl eher eines der Hauptprobleme.

> http://sunsite.univie.ac.at/textbooks/mysql/manual.html#Brok en_Foreign_KEY
>
> ,----[ Zitat ]
> | Foreign key constraints make life very complicated,
> `----
>
> und
>
> ,----[ Zitat ]
> | The only nice aspect of FOREIGN KEY is that it gives ODBC and some other
> | client programs the ability to see how a table is connected and to use
> | this to show connection diagrams and to help in building applications.
> `----

Naja, Stand April 2001.

>> Ich habe mal bei einem meiner Provider per PHPMyAdmin geguckt, was für
>> Typen angeboten werden:
>> Default engine as of MySQL 3.23 with great performance: MyISAM
>
> Da fehlt noch eine ganz großartige:
> http://www.mysql.org/doc/refman/5.0/en/blackhole-storage-eng ine.html
>
> Die ist *richtig* schnell.

Ja, aber... er hat doch nur 3.23...

Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Normalisierung: brauche Tipp...

am 03.07.2007 15:19:09 von Andreas Kretschmer

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Normalisierung: brauche Tipp...

am 03.07.2007 22:50:01 von Andreas Scherbaum

i.steinhardt@web.de wrote:
> On 3 Jul., 11:48, Andreas Scherbaum wrote:
>
>> > FKs sind eine feine Sache - aber wie läuft die Sache mit "Nativ-MySQL"
>> > ohne FK?
>>
>> "Nativ-MySQL", wie du es so schön nennst, bringt InnoDB mit. Man muss
>> das nur nutzen (wollen). Wenn du keine FK brauchst, suchst du eigentlich
>> keine Datenbank sondern ein Datengrab. Aber dann können die Daten auch
>> nicht so wichtig sein.
>>
>
> in den MySQL-Büchern (ggf. schon etwas angestaubt) ist zu lesen: "das
> Fehlen von FKs kann verschmerzt werden, da diese mit entsprechender
> Programmlogik ersetzt werden können..."
>
> Ich habe mal bei einem meiner Provider per PHPMyAdmin geguckt, was für
> Typen angeboten werden:
> Default engine as of MySQL 3.23 with great performance: MyISAM
> Hash based, stored in memory, useful for temporary tables: MEMORY
> Archive storage engine: ARCHIVE
> CSV storage engine: CSV
> Federated MySQL storage engine: FEDERATED
> Collection of identical MyISAM tables: MRG_MYISAM
>
> von InnoDB nix zu sehen...

Wir sprechen nicht von angestaubten und ranzigen Versionen, die seit
Jahrzehnten nicht mehr supported werden, sorry. Selbst Mysql ist da
in den letzten Jahren ein Stück erwachsener geworden.

http://www.mysql.com/company/legal/lifecycle/

Version 3.x hat schon nicht mal mehr Extended Support, wenn dein
Provider dir so etwas noch anbietet, ist das schon fahrlässig.

An deiner Stelle würde ich mir einen anderen Provider suchen.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Normalisierung: brauche Tipp...

am 03.07.2007 22:53:16 von Andreas Scherbaum

Gregor Kofler wrote:
> Andreas Kretschmer meinte:
>
>> Ja. Das ist eines der Hauptprobleme von MySQL: fehlende Features wurden
>> als Plus der DB verkauft. Besonders schön z.B. hier:
>
> Es *war* wohl eher eines der Hauptprobleme.
>
>> http://sunsite.univie.ac.at/textbooks/mysql/manual.html#Brok en_Foreign_KEY
>>
>> ,----[ Zitat ]
>> | Foreign key constraints make life very complicated,
>> `----
>>
>> und
>>
>> ,----[ Zitat ]
>> | The only nice aspect of FOREIGN KEY is that it gives ODBC and some other
>> | client programs the ability to see how a table is connected and to use
>> | this to show connection diagrams and to help in building applications.
>> `----
>
> Naja, Stand April 2001.

Abgesehen davon, das wir offtopic werden:
Warum hat Mysql all diese Features heute, wenn sie ein oder zwei Versionen,
bevor sie aufgetaucht sind, noch als unnötig und kompliziert eingestuft wurden?


>> Da fehlt noch eine ganz großartige:
>> http://www.mysql.org/doc/refman/5.0/en/blackhole-storage-eng ine.html
>>
>> Die ist *richtig* schnell.
>
> Ja, aber... er hat doch nur 3.23...

Da hat er jetzt wohl Pech, muss er mit einer langsameren Engine arbeiten?
*smile*


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Normalisierung: brauche Tipp...

am 04.07.2007 07:01:19 von Norbert Tretkowski

Am Tue, 03 Jul 2007 22:53:16 +0200 schrieb Andreas Scherbaum:
> Warum hat Mysql all diese Features heute, wenn sie ein oder zwei
> Versionen, bevor sie aufgetaucht sind, noch als unnötig und kompliziert
> eingestuft wurden?

"Selbst Mysql ist da in den letzten Jahren ein Stück erwachsener
geworden."

-- Andreas Scherbaum in

Re: Normalisierung: brauche Tipp...

am 04.07.2007 12:02:27 von i.steinhardt

@all

bei meinem Provider läuft MySQL-Client-Version: 4.1.15 - ist die
InnoDB ggf. abgeschaltet, da größerer Speicherbedarf oder RAM-
Belasung ???

Neben einigen anderen Büchern wie MySQL/PHP von Jay Greenspan habe ich
auch das aktuelle von Michael Koffler - aber haben und wissen sind
bekanntlich zwei Paar Schuhe... ;-)

Zurück zum Thema:
gibt es denn noch eine "elegante" Lösung, die ich bei meinem Provider
umsetzten kann??

Dank&Gruss
Ingolf

Re: Normalisierung: brauche Tipp...

am 04.07.2007 12:13:17 von Norbert Tretkowski

* i.steinhardt schrieb:
> bei meinem Provider läuft MySQL-Client-Version: 4.1.15
^^^^^^
Das ist der Client.

> ist die InnoDB ggf. abgeschaltet, da größerer Speicherbedarf oder RAM-
> Belasung ???

Das solltest du deinen Provider fragen.

Norbert

Re: Normalisierung: brauche Tipp...

am 04.07.2007 12:37:41 von Gregor Kofler

i.steinhardt@web.de meinte:
> @all
>
> bei meinem Provider läuft MySQL-Client-Version: 4.1.15 - ist die

Das ist die Client-Version. Was ist denn die Server-Version?

> InnoDB ggf. abgeschaltet, da größerer Speicherbedarf oder RAM-
> Belasung ???

Frag deinen Provider, warum er InnoDB abschaltet.

> Neben einigen anderen Büchern wie MySQL/PHP von Jay Greenspan habe ich
> auch das aktuelle von Michael Koffler - aber haben und wissen sind
> bekanntlich zwei Paar Schuhe... ;-)

Ja, aber *lesen* muss man die schon auch noch. Ich kenn nur den Kofler,
aber der nimmt einen ja eh bei der Hand.

> Zurück zum Thema:
> gibt es denn noch eine "elegante" Lösung, die ich bei meinem Provider
> umsetzten kann??

Wenn du schon auf diesen Provider und somit MyISAM scharf bist, musst du
eben (zumindest eingeschränkte) referentielle Integrität im Programmcode
"nachbauen".

Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Normalisierung: brauche Tipp...

am 04.07.2007 14:07:30 von i.steinhardt

@ Norbert & Georg

als Server-Version kommt als Ausgabe "5.0.32-Debian_7etch1~bpo.1-log"

Ich werde mal eine Mail an den Support senden warum InnoDB
"ausgegraut" ist.

Dank&Gruss

Ingolf

Re: Normalisierung: brauche Tipp...

am 04.07.2007 14:11:11 von Andreas Kretschmer

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Normalisierung: brauche Tipp...

am 04.07.2007 21:45:11 von Andreas Scherbaum

Gregor Kofler wrote:
> i.steinhardt@web.de meinte:
>
>> Zurück zum Thema:
>> gibt es denn noch eine "elegante" Lösung, die ich bei meinem Provider
>> umsetzten kann??
>
> Wenn du schon auf diesen Provider und somit MyISAM scharf bist, musst du
> eben (zumindest eingeschränkte) referentielle Integrität im Programmcode
> "nachbauen".

Oh Man, nu lasst uns doch nicht wieder mit diesen Würgarounds anfangen,
jetzt, da Mysql gelernt hat, das man FK doch zu etwas sinnvollerem als zur
ODBC Unterstützung nutzen kann ...


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Normalisierung: brauche Tipp...

am 04.07.2007 23:11:10 von Gregor Kofler

Andreas Scherbaum meinte:
> Gregor Kofler wrote:

> Oh Man, nu lasst uns doch nicht wieder mit diesen Würgarounds anfangen,
> jetzt, da Mysql gelernt hat, das man FK doch zu etwas sinnvollerem als zur
> ODBC Unterstützung nutzen kann ...

Ich tu's ja eh nicht.

Aber wenn der OP eine Engine ohne RI nutzen will, dann *muss* er
sichwohl selber drum kümmern. Oder einfach auf dieses FK-Zeugs schei...en.

Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum