Frage zum DB-Design

[Ludger]

Hi,

mal eine Frage an die Spezialisten des DB-Designs:
gegeben sind Vertraege und Vertragsgegenstaende, wobei eine many to many-Beziehung vorliegt mit der Einschraenkung, dass ein Vertragsgegenstand einem Vertrag maximal einmal zugeordnet werden kann

Wie wuerdet Ihr diese Einstellung realisieren?
a) mit MySQL ?
b) M$ SQL Server ?
c) Oracle Datenserver ?

Gruss,
Ludger

[Cheatah]

Hi,

Wie wuerdet Ihr diese Einstellung realisieren?

mit einer Verknüpfungstabelle und Unique-Constraint (z.B. PK) auf beide Verknüpfungsspalten. Das dürfte in allen DBMSsen weitgehend gleich sein. Als dritte Spalte könnte sich ggf. die Position anbieten, was natürlich nicht ganz unproblematisch ist; vermutlich wirst Du nur zwei Spalten verwenden wollen. Index über alle Spalten, die Reihenfolge hängt von Deiner Wunschselektion und -sortierung ab.

Cheatah

[Ludger]

Hi,

Wie wuerdet Ihr diese Einstellung realisieren?

mit einer Verknüpfungstabelle und Unique-Constraint (z.B. PK) auf beide Verknüpfungsspalten.

also sowas:

Vertraege (DBTabelle)
Vertrag_GUID (Datenfeld)
Vertrag_ID (Datenfeld)
Vertrag_Timestamp (Datenfeld)
...

Vertragsgegenstaende (DBTabelle)
Vertragsgegenstand_GUID (Datenfeld)
Vertragsgegenstand_Timestamp (Datenfeld)
...

Vertraege_Vertragsgegenstaende_Relationships (DBTabelle)
Vertraege_Vertragsgegenstaende_Relationship_GUID (Datenfeld)
Vertraege_Vertragsgegenstaende_Relationship_Timestamp (Datenfeld)
Vertraege_Vertragsgegenstaende_Relationship_Vertrag_GUID (Ddatenfeld)
Vertraege_Vertragsgegenstaende_Relationship_Vertragsgegenstand_GUID (Datenfeld)

Das dürfte in allen DBMSsen weitgehend gleich sein.

Denke ich auch.

Als dritte Spalte könnte sich ggf. die Position anbieten, was natürlich nicht ganz unproblematisch ist;

Meinst Du die Position eines Vertragsgegenstandes innerhalb eines Vertrags (Das ist nicht angefordert) oder etwas anderes?

vermutlich wirst Du nur zwei Spalten verwenden wollen. Index über alle Spalten, die Reihenfolge hängt von Deiner Wunschselektion und -sortierung ab.

OK, aber die Sache mit der "Einschraenkung, dass ein Vertragsgegenstand einem Vertrag maximal einmal zugeordnet werden kann", war die eigentliche Herausforderung fuer die drei genannten DBMSe.

Gruss nach Karlsruhe!
Ludger

[Cheatah]

Hi,

also sowas:

es ist nicht nötig, in den Spaltennamen den Namen der Tabelle zu wiederholen. Enthalten die "_GUID"-Spalten die Datensatz-IDs?

Vertraege_Vertragsgegenstaende_Relationships (DBTabelle)
Vertraege_Vertragsgegenstaende_Relationship_GUID (Datenfeld)

Wenn ja, wäre diese Spalte beispielsweise unnötig, weil sie sich aus Vertrag_GUID und Vertragsgegenstand_GUID ergibt.

Vertraege_Vertragsgegenstaende_Relationship_Timestamp (Datenfeld)

Ob dies nötig ist, kann ich nicht beurteilen. Ist es eine Art Eintrags- oder Änderungs-Zeitpunkt?

Als dritte Spalte könnte sich ggf. die Position anbieten, was natürlich nicht ganz unproblematisch ist;

Meinst Du die Position eines Vertragsgegenstandes innerhalb eines Vertrags (Das ist nicht angefordert) oder etwas anderes?

Ja, genau das. Schön, wenn Du es weglassen kannst :-)

OK, aber die Sache mit der "Einschraenkung, dass ein Vertragsgegenstand einem Vertrag maximal einmal zugeordnet werden kann", war die eigentliche Herausforderung fuer die drei genannten DBMSe.

Sie spiegelt sich im Fehlen einer ID-Spalte wider ;-)

Gruss nach Karlsruhe!

Und zurück!

Cheatah

[Ludger]

Hi,

also sowas:

es ist nicht nötig, in den Spaltennamen den Namen der Tabelle zu wiederholen. Enthalten die "_GUID"-Spalten die Datensatz-IDs?

Die GUIDs sind fuer mich globale ("Netzwerkkarten-ID abhaengige") IDs (oft Hexwerte), waehrend die IDs fuer mich benutzerfreundliche Datentabellen-eindeutige IDs sind, also oft Integers.
Die Namenskonvention hat sich so ergeben, damit man DB-eindeutige Datenfeldnamen hat, was sich als guenstig erwiesen hat fuer die Kommunikation und fuer die Intuitivitaet komplexer Abfragen bspw..

Vertraege_Vertragsgegenstaende_Relationships (DBTabelle)
Vertraege_Vertragsgegenstaende_Relationship_GUID (Datenfeld)

Wenn ja, wäre diese Spalte beispielsweise unnötig, weil sie sich aus Vertrag_GUID und Vertragsgegenstand_GUID ergibt.

Wir haben da bestimmte Vorgaben die ID-Gebung betreffend.
Du schlaegst aber anscheinend einen kombinierten Primaerschluessel vor, der dann natuerlicherweise eine doppelte Zuordnung eines Gegenstands zu einem Vertrag unterbinden wuerde. Aha, gute Idee, leider bei uns nicht zugelassen. Haette ich dazuschreiben sollen, aber ich hatte Deinen Loesungsvorschlag nicht antizipieren koennen.   :-(

Vertraege_Vertragsgegenstaende_Relationship_Timestamp (Datenfeld)

Ob dies nötig ist, kann ich nicht beurteilen. Ist es eine Art Eintrags- oder Änderungs-Zeitpunkt?

Vorgaben. (Historisierung, Stndardisierung und so)

Als dritte Spalte könnte sich ggf. die Position anbieten, was natürlich nicht ganz unproblematisch ist;

Meinst Du die Position eines Vertragsgegenstandes innerhalb eines Vertrags (Das ist nicht angefordert) oder etwas anderes?

Ja, genau das. Schön, wenn Du es weglassen kannst :-)

Wirklich schoen.   :-)
Allerdings werde ich da sofort neugierig und frage mich, wie man so was idealerweise macht. (Datentyp Integer und die Regel, dass doppelte Werte unzulaessig (CHECK-Constraint)?)

Gruss,
Ludger

[Daniela Koller]

Hi Ludger

Du schlaegst aber anscheinend einen kombinierten Primaerschluessel vor, der dann natuerlicherweise eine doppelte Zuordnung eines Gegenstands zu einem Vertrag unterbinden wuerde. Aha, gute Idee, leider bei uns nicht zugelassen. Haette ich dazuschreiben sollen, aber ich hatte Deinen Loesungsvorschlag nicht antizipieren koennen.   :-(

Aber Unique-Indizes über mehrere Spalten werden wohl zulässig sein? Die kann man auch ganz normal benutzen ohne das sie implizit durch einen Primärschlüssel erstellt werden.

Gruss Daniela

[Ludger]

Hi,

Aber Unique-Indizes über mehrere Spalten werden wohl zulässig sein? Die kann man auch ganz normal benutzen ohne das sie implizit durch einen Primärschlüssel erstellt werden.

interessanter Ansatz Indizes fuer Einstellungen auf Datensatzebene zu nutzen.

Ich habe mal mit M$ SQL Server folgende Tabelle (incl. PK einem Defaultwert und dem von Dir vorgeschlagenenen Index) erstellt:

-- die Test-Tabelle
CREATE TABLE [dbo].[Tests] (
 [Test_GUID] [uniqueidentifier] NOT NULL ,
 [Test_GUID_1] [uniqueidentifier] NOT NULL ,
 [Test_GUID_2] [uniqueidentifier] NOT NULL
) ON [PRIMARY]
GO

-- der PK
ALTER TABLE [dbo].[Tests] WITH NOCHECK ADD
 CONSTRAINT [PK_Tests] PRIMARY KEY  CLUSTERED
 (
  [Test_GUID]
 )  ON [PRIMARY]
GO

-- der Defaultwert fuer den PK und der kombinierte unique Index
ALTER TABLE [dbo].[Tests] WITH NOCHECK ADD
 CONSTRAINT [DF_Tests_Test_GUID] DEFAULT (newid()) FOR [Test_GUID],
 CONSTRAINT [IX_Tests] UNIQUE  NONCLUSTERED
 (
  [Test_GUID_1],
  [Test_GUID_2]
 )  ON [PRIMARY]
GO

Dann fuehrt beispielsweise ein wiederholtes
 insert
  tests
  (
  Test_GUID,
  test_guid_1,
  test_guid_2
  )
 values
  (
  newid(),
  '{137477E5-1591-4279-9962-4E20E25E2EAA}',
  '{CBC12F5B-A556-462D-8B7F-1F6DC29DFE8F}'
  )
zur Fehlermeldung:
Server: Nachr.-Nr. 2627, Schweregrad 14, Status 2, Zeile 1
Verletzung der UNIQUE KEY-Einschränkung 'IX_Tests'. Ein doppelter Schlüssel kann in das Tests-Objekt nicht eingefügt werden.
Die Anweisung wurde beendet.

Ist das ueblich Indizes auf diese Art und Weise zu nutzen? Ist das OK es zu tun?

Gruss,
Ludger

[Daniela Koller]

Hi Ludger

Ist das ueblich Indizes auf diese Art und Weise zu nutzen? Ist das OK es zu tun?

Es ist üblich, Primärschlüssel auf diese Weise zu nutzen. Klar könntest du afair zumindest mit Oracle bei jedem Insert ein PL/SQL-Statement aufrufen, dass prüft ob schon sowas existiert, bei MySQL hättest du damit aber doch Probleme und müsstest das händisch vor jedem Schreibzugriff prüfen. Um zu prüfen ob schon ein solcher Datensatz schon existiert, musst du die Daten aber auch lesen. Ein normaler Index über beide Spalten wäre also sowieso empfehlenswert. Warum also nicht gleich die Arbeit von der DB erledigen lassen?

Achja, mir fällt nur eine einzige Sache ein, die gegen zusammengesetzte Primärschlüssel spricht: Bei Fremdschlüsselbeziehungen müssen immer alle Felder benutzt werden, das kann etwas mühsam werden. Ansonsten mag ich zusammengesetzte Primärschlüssel und allgemein natürliche Schlüssel soweit existent sehr gerne.

Gruss Daniela

[Cheatah]

Hi,

Aber Unique-Indizes über mehrere Spalten werden wohl zulässig sein? Die kann man auch ganz normal benutzen ohne das sie implizit durch einen Primärschlüssel erstellt werden.
interessanter Ansatz Indizes fuer Einstellungen auf Datensatzebene zu nutzen.

eigentlich nicht, wenn man mal drüber nachdenkt. Du möchtest ein Unique-Constraint haben; gut, das ginge theoretisch auch ohne Index. Wenn nun aber etwas in die Tabelle eingefügt (oder aktualisiert) werden soll, muss das DBMS zunächst prüfen, dass die Wertekombination in der Tabelle noch nicht existiert, sinngemäß ist das nichts anderes als ein

SELECT 1 FROM tabelle WHERE spalte=wert ...

Soll das nun ein Full Table Scan werden? Wohl eher nicht. Also muss ein Index her.

Fazit: Ein Unique-Constraint _ist_ ein Index (mit einer speziellen Eigenschaft).

Ist das ueblich Indizes auf diese Art und Weise zu nutzen? Ist das OK es zu tun?

Alles andere wäre hier falsch :-)

Cheatah

[Cheatah]

Hi,

Wir haben da bestimmte Vorgaben die ID-Gebung betreffend.

das spricht für euch. Eure Vorgaben kenne ich natürlich nicht, aber ich denke, Du hast schon die nötigen Fähigkeiten, diese zusätzlich zum Benötigten umzusetzen ;-) Ich kann Dir nur sagen, was für die Aufgabe gebraucht wird.

Du schlaegst aber anscheinend einen kombinierten Primaerschluessel vor, der dann natuerlicherweise eine doppelte Zuordnung eines Gegenstands zu einem Vertrag unterbinden wuerde. Aha, gute Idee, leider bei uns nicht zugelassen.

Über diese Vorgabe solltet ihr allerdings noch mal nachdenken. Zwar spricht (fast) nichts gegen eine zusätzliche ID-Spalte, aber aus Sicht der Aufgabenstellung wird für das DB-Layout ganz klar ein PK über beide Spalten erfordert. Alles andere wäre ein - wenn auch nicht schlimmer - Fehler.

Allerdings werde ich da sofort neugierig und frage mich, wie man so was idealerweise macht. (Datentyp Integer und die Regel, dass doppelte Werte unzulaessig (CHECK-Constraint)?)

Siehe oben und Danielas Antwort :-)

Cheatah

[Ludger]

Hi,

Über diese Vorgabe solltet ihr allerdings noch mal nachdenken. Zwar spricht (fast) nichts gegen eine zusätzliche ID-Spalte, aber aus Sicht der Aufgabenstellung wird für das DB-Layout ganz klar ein PK über beide Spalten erfordert. Alles andere wäre ein - wenn auch nicht schlimmer - Fehler.

kombinierte PKs werden bei uns nicht gerne gesehen, denn die sind

• nie erforderlich
• schwerer zu handeln
• vermutlich nur sinnvoll, wenn sie auf kombinierte PKs verweisen
• und wenn nicht, also, wenn die auf einmal Bedeutung transportieren, unter Umstaenden ganz ganz unangenehm

Gruss,
Ludger

[Matzberger Marcus]

Hallo,

Hi,

Über diese Vorgabe solltet ihr allerdings noch mal nachdenken. Zwar spricht (fast) nichts gegen eine zusätzliche ID-Spalte, aber aus Sicht der Aufgabenstellung wird für das DB-Layout ganz klar ein PK über beide Spalten erfordert. Alles andere wäre ein - wenn auch nicht schlimmer - Fehler.

kombinierte PKs werden bei uns nicht gerne gesehen, denn die sind

• nie erforderlich
• schwerer zu handeln
• vermutlich nur sinnvoll, wenn sie auf kombinierte PKs verweisen
• und wenn nicht, also, wenn die auf einmal Bedeutung transportieren, unter Umstaenden ganz ganz unangenehm

Nie erforderlich ist relativ. Wenn ich eine Zuordnungstabelle habe, die nichts anderes tut als eine m:n in 2 1:m aufzulösen (wie im Beispiel) kann ich natürlich eine zusätzliche ID-Spalte anlegen. Geht allerdings, wenn auch nicht spektakulär, auf die Performance, da die ID-Spalte als Primärschlüssel einen zusätzlichen Index fordert, der verwaltet werden muss. Aus diesem Grund bietet Oracle ab 9i auch die Möglichkeit eine solche Tabelle als index-organized anzulegen, die dann nur aus dem Index der 2 Spalten besteht und die Daten nicht zusätzlich speichert.

Grüße
Marcus

[Cheatah]

Hi,

kombinierte PKs werden bei uns nicht gerne gesehen, denn die sind

• nie erforderlich

siehe Marcus' Antwort :-)

• schwerer zu handeln

Nein - Du referenzierst ja niemals auf diese Tabelle, sondern nur _von_ derselben auf andere Tabellen. In der Praxis merkst Du überhaupt nicht, dass da ein PK über zwei Spalten geht. Es ist einfach so, und das war's.

• vermutlich nur sinnvoll, wenn sie auf kombinierte PKs verweisen

Nö :-) Sie verweisen hier auf zwei verschiedene, jeweils einspaltige PKs.

Cheatah

[Ludger]

Hi,

• nie erforderlich

siehe Marcus' Antwort :-)

Du verweist in diesem Thread fuer meinen Geschmack zu oft auf andere Beitraege. Das, was da gesagt wurde (Performance und so, das ueberlasse ich den Finetunern unter uns, also den Nicht-Finanzdienstleistern ;-), ist fuer mich von keinem besonderen Interesse. Bemerkenswert bestenfalls das Oracle-Feature "n:m"-Beziehungen intern zu verwalten.

• schwerer zu handeln

Nein - Du referenzierst ja niemals auf diese Tabelle, sondern nur _von_ derselben auf andere Tabellen. In der Praxis merkst Du überhaupt nicht, dass da ein PK über zwei Spalten geht. Es ist einfach so, und das war's.

Moment, die Tabellen sind doch ueber PKs verzeigert. Wenn Du jetzt Abfragen schreibst und eine Verzeigerung (es war eine unserer "Spezialiataeten" mit NiederlassungID (z.B. '013') und einem Integerwert (z.B. Anfragennummer) Eindeutigkeiten zu bilden) vergisst (z.B. die NiederlassungsID), dann gab es merkwuerdige Resultate. (Schoen waren dann auch so Sachen wie das Aendern einer NLID von bspw. '011' auf '111'.)

Gruss,
Ludger

[Cheatah]

Hi,

Du verweist in diesem Thread fuer meinen Geschmack zu oft auf andere Beitraege.

naja, ich könnte den Text auch einfach kopieren, aber das würde auch nicht mehr helfen ...

Das, was da gesagt wurde (Performance und so, das ueberlasse ich den Finetunern unter uns, also den Nicht-Finanzdienstleistern ;-), ist fuer mich von keinem besonderen Interesse.

Der Grund, weshalb ich andere Artikel erwähne ist, dass ich sie als interessant für Dich erachte. Natürlich auch, weil dort ziemlich genau das steht, was ich geantwortet hätte. Insofern solltest Du das nicht vorhandene besondere Interesse ggf. relativieren :-)

Nein - Du referenzierst ja niemals auf diese Tabelle, sondern nur _von_ derselben auf andere Tabellen. In der Praxis merkst Du überhaupt nicht, dass da ein PK über zwei Spalten geht. Es ist einfach so, und das war's.
Moment, die Tabellen sind doch ueber PKs verzeigert.

Nein, über FKs[1]. Eine Verknüpfungstabelle hat die Eigenschaft, dass _sie_ die Foreign Keys besitzt, nicht die Tabellen, die verknüpft werden.

Wenn Du jetzt Abfragen schreibst und eine Verzeigerung (es war eine unserer "Spezialiataeten" mit NiederlassungID (z.B. '013') und einem Integerwert (z.B. Anfragennummer) Eindeutigkeiten zu bilden) vergisst (z.B. die NiederlassungsID), dann gab es merkwuerdige Resultate.

Ähm, verstehe mich bitte nicht falsch; aber wenn Du eine falsche Abfrage schreibst, dann _hoffe_ auf merkwürdige Resultate, weil Du sonst den Fehler schwerer bemerkst :-)

Cheatah

[1] Ein FK _zeigt_ zwar auf einen PK, aber der PK alleine bringt überhaupt keine Verzeigerung. Wir haben viele Tabellen, die zwar über einen PK verfügen, aber von nirgendwo aus referenziert werden.

[Ludger]

Hi,

Ähm, verstehe mich bitte nicht falsch; aber wenn Du eine falsche Abfrage schreibst, dann _hoffe_ auf merkwürdige Resultate, weil Du sonst den Fehler schwerer bemerkst :-)

nach unserer Philosophie muss der Entwickler minimal wenig wissen und minimal schlau sein um bspw. einen Job zu erledigen. Einfachheit heisst die Devise, der wir folgen. Nun ist ja der Finanzdienstleister in der Tat scheinbar doefer als der Techie. Und das muss man eben irgendwie ausgleichen.   ;-)

[1] Ein FK _zeigt_ zwar auf einen PK, aber der PK alleine bringt überhaupt keine Verzeigerung. Wir haben viele Tabellen, die zwar über einen PK verfügen, aber von nirgendwo aus referenziert werden.

Ich dachte Rechtschreibfehler und offensichtliche Versehen in der Sache werden hier nicht debattiert. Ich hatte doch ein energisches und, wie ich finde, wohlbegruendetes Plaedoyer gegen zusammengesetzte PKs vorgetragen. Nicht mehr und nicht weniger.

Und wenn man manchmal zusammengesetzte PKs als zulaessig durchgehen laesst und nur manchmal nicht, dann hat man natuerlich immer Diskussionsbedarf. Dann kommen auch die Freunde der Performance und der Komplexitaet zu ihrem Recht. Und genau das will man nicht in der Finanzdienstleistung, denn das rechnet sich nicht. (Zumindest solange ich hier noch etwas zu sagen habe!  ;-)

Gruss,
Ludger

[Cheatah]

Hi,

nach unserer Philosophie muss der Entwickler minimal wenig wissen und minimal schlau sein um bspw. einen Job zu erledigen. Einfachheit heisst die Devise, der wir folgen.

Kenntnisse der strukturellen Zusammenhänge _sind_ das Minimum an Wissen. Willst Du dies einem Entwickler nicht auferlegen, so stelle eine Schnittstelle zur Verfügung, die ihm diese Kenntnisse abnimmt.

Übrigens würde ich die Philosophie dahingehend abändern, dass er _maximal_ schlau sein sollte ... :-)

[1] Ein FK _zeigt_ zwar auf einen PK, aber [...]
Ich dachte Rechtschreibfehler und offensichtliche Versehen in der Sache werden hier nicht debattiert.

Daher ist dies ja auch nur eine Fußnote.

Ich hatte doch ein energisches und, wie ich finde, wohlbegruendetes Plaedoyer gegen zusammengesetzte PKs vorgetragen. Nicht mehr und nicht weniger.

Naja, wohlbegründet finde ich es nicht. Zumindest hat es mich nicht davon überzeugt, dass PKs nicht anhand der Eigenschaften der Daten gewählt werden müssten.

Und wenn man manchmal zusammengesetzte PKs als zulaessig durchgehen laesst und nur manchmal nicht, dann hat man natuerlich immer Diskussionsbedarf.

Zusammengesetzte PKs sind _immer_ zulässig und _meistens_ nicht sinnvoll. So einfach ist das :-)

Dann kommen auch die Freunde der Performance und der Komplexitaet zu ihrem Recht. Und genau das will man nicht in der Finanzdienstleistung, denn das rechnet sich nicht. (Zumindest solange ich hier noch etwas zu sagen habe!  ;-)

Nun ja, aufgrund von Prinzipien auf eine sinnvolle, mehr noch: notwendige Einstellung zu verzichten, trägt einen treffenden Namen: Broken As Designed, kurz BAD. Ich empfehle Dir, Richtlinien nur über Dinge zu treffen, deren Notwendigkeit Deiner Kontrolle unterliegt. Auf grundsätzliche Formen des DB-Layouts trifft dies definitiv nicht zu.

Cheatah

[Ludger]

Hi,

nach unserer Philosophie muss der Entwickler minimal wenig wissen und minimal schlau sein um bspw. einen Job zu erledigen. Einfachheit heisst die Devise, der wir folgen.

Kenntnisse der strukturellen Zusammenhänge _sind_ das Minimum an Wissen.

es geht auch darum dem Entwickler nur ein Minimum an Wissen um strukturelle Zusammenhaenge zumuten zu muessen.

Übrigens würde ich die Philosophie dahingehend abändern, dass er _maximal_ schlau sein sollte ... :-)

Gerade so schlau wie erforderlich, darum auch gut ersetzbar, nicht hinterhaeltig und kostenguenstig verfuegbar. So sieht der ideale Entwickler aus Sicht des Kaufmanns aus.

Nun ja, aufgrund von Prinzipien auf eine sinnvolle, mehr noch: notwendige Einstellung zu verzichten, trägt einen treffenden Namen: Broken As Designed, kurz BAD.

Mein Autokennzeichen faengt so an, meine Vorstellungen allerdings nicht.   ;-)

Ich empfehle Dir, Richtlinien nur über Dinge zu treffen, deren Notwendigkeit Deiner Kontrolle unterliegt. Auf grundsätzliche Formen des DB-Layouts trifft dies definitiv nicht zu.

War nicht ganz ernstgemeint. Stenggenommen haben wir keine Richtlinien. Aber ich habe schon so viel Murks mit bedeutungsbelasteten PKs (zusammengesetzt aus drei Datenfeldern z.B.) aushalten muessen. Aber an meiner Empfehlung nie, zusammengesetzte PKs zu nutzen, halte ich dennoch fest.

Gruss,
Ludger

[Matzberger Marcus]

Hallo,

Gerade so schlau wie erforderlich, darum auch gut ersetzbar, nicht hinterhaeltig und kostenguenstig verfuegbar. So sieht der ideale Entwickler aus Sicht des Kaufmanns aus.

In diesem Fall kann es aber auch bedeuten aufgrund von Performanceproblemen ständig die Hardware erweitern zu müssen. Hilft das nichts muss die Software umgeschrieben werden. Wir hatten vor Kurzem das Problem durch Integration eines anderen Systems die DB bis an den Anschlag auszulasten. Die Anwender waren durch die Wartezeiten nicht beglückt. Und wenn 400 Anwender auf jede der ca. 50 Anfragen täglich 1 Minute länger warten müssen sollten auch einem Kaufmann die Haare zu berge stehen.

Grüße
Marcus

[Ludger]

Hi,

Gerade so schlau wie erforderlich, darum auch gut ersetzbar, nicht hinterhaeltig und kostenguenstig verfuegbar. So sieht der ideale Entwickler aus Sicht des Kaufmanns aus.

In diesem Fall kann es aber auch bedeuten aufgrund von Performanceproblemen ständig die Hardware erweitern zu müssen. Hilft das nichts muss die Software umgeschrieben werden. Wir hatten vor Kurzem das Problem durch Integration eines anderen Systems die DB bis an den Anschlag auszulasten. Die Anwender waren durch die Wartezeiten nicht beglückt. Und wenn 400 Anwender auf jede der ca. 50 Anfragen täglich 1 Minute länger warten müssen sollten auch einem Kaufmann die Haare zu berge stehen.

es sind aber in aller Regel die so genannten OLAP-Queries, die - oft schlecht geschrieben - von Controllern und so ;-) - die Performancekiller sind. Oder nette kleine Replikationsloesungen (bspw. von M$) mit vertikaler und horizontaler Filterung und ein klein wenig VBScript-Transformierungscode die das Programmiererherz hoeher schlagen lassen, und zwar vor lauter dummer Freude an der eigenen Unschuld am Performance-GAU. Oder Datentransport- und Datentransformationsjobs, die anscheinend immer laufen und die so genannten OLTP-Anwendungen in Mitleidenschaft ziehen - "Haengt den DBA!"-Rufe werden laut.

Gruss,
Ludger

[Matzberger Marcus]

Hallo,

es sind aber in aller Regel die so genannten OLAP-Queries, die - oft schlecht geschrieben - von Controllern und so ;-) - die Performancekiller sind.

Deshalb stellen die bei uns für Abfragen Anforderungen an die Entwickler, die dafür sorgen, dass sie performant sind ;-)

Grüße
Marcus

[Matzberger Marcus]

Hallo,

Du verweist in diesem Thread fuer meinen Geschmack zu oft auf andere Beitraege. Das, was da gesagt wurde (Performance und so, das ueberlasse ich den Finetunern unter uns, also den Nicht-Finanzdienstleistern ;-), ist fuer mich von keinem besonderen Interesse. Bemerkenswert bestenfalls das Oracle-Feature "n:m"-Beziehungen intern zu verwalten.

Das den Feintunern zu überlassen ist ein schwerer Fehler, denn Feintuning kann nicht darin bestehen das Tabellendesign zu ändern.
Daher ist es auch für dich von Interesse, denn entweder bist du für das Datenbankdesign zuständig, dann musst du dich von vorneherein darum kümmern, oder du sagst das interessiert dich nicht, warum machst du dir dann Gedanken über zusammengesetzte Primärschlüssel?

?-(

Grüße
Marcus

[Ludger]

Hi,

Das den Feintunern zu überlassen ist ein schwerer Fehler, denn Feintuning kann nicht darin bestehen das Tabellendesign zu ändern.

das sind, wie bereits geschrieben, Performanceueberlegungen. Geraete und damit CPU-Zeit haben wir aber genug. (Bitte nicht ans Betriebsteam weiterreichen. Das B-Team macht mir sowieso schon Sorgen. ;-)

Daher ist es auch für dich von Interesse, denn entweder bist du für das Datenbankdesign zuständig, dann musst du dich von vorneherein darum kümmern, oder du sagst das interessiert dich nicht, warum machst du dir dann Gedanken über zusammengesetzte Primärschlüssel?

Weil zusammengesetzte PKs boese sind, zumindest unter wirtschaftlichen Gesichtspunkten. Dass diese bei einer Hilfstabelle fuer "n:m"-Beziehungen - sofern ich alles richtig verstanden habe, wovon ich aber einfach mal ausgehe - die optimale Loesung darstellen, will ich doch gar nicht bezweifeln. Die sind also boese und stellen manchmal die optimale Loesung dar. Ist doch logisch und kohaerent, oder?   :-)

Gruss,
Ludger