dbms mit tabellen die vererbt werden können?

[TobiasBuschi]

Hallo ihr Datenbankspezialisten

Gibt ein Konzept oder ein Standard der in einer Db vererben von Tabellen beschreibt?
Am besten erkläre ich meine Idee in einem Beispiel:

CREATE TABLE product {
  id int autoincrement
  name varchar 255
  preis float
}

CREATE TABLE monitor EXTENDS product {  /// <------ EXTENDS
  gewicht int
  resolution_x int
  resolution_y int
}

CREATE TABLE drucker EXTENDS product {   /// <------ EXTENDS
  gewicht int
  auflösung int
  geschwindigkeit int
}

Dann sollte man abfragen machen können wie:

SELECT id, name, gewicht // FROM product bedeutet auch FROM
FROM product             // monitor und drucker da diese ja auch
WHERE gewicht < 2        // Produkte sind

Und erhält z.B.

id | name            | gewicht   | __entity__
---------------------------------------------------
2  | EIZO Bildschirm | 4         | monitor
4  | HP Bildschirm   | 3         | monitor
5  | DELL Bildschirm | 3         | monitor
8  | BElinea Bildsc. | 5         | monitor
1  | HP Drucker      | 2         | drucker
89 | EPSON DRUCKER 2 | 1         | drucker

Ein solches Konzept fehlt mir extrem!
Viel mehr als so neue Ansätze wie oodbms und xml-Datenbanken

Was meint Ihr?

TobiasBuschi

[Ijla]

yo,

Gibt ein Konzept oder ein Standard der in einer Db vererben von Tabellen beschreibt?

Was meint Ihr?

meine ganz persönliche meingung dazu ist, zur zeit würde ich keine objektorientierten ansätze in das datendesign eines rdbms mit einbringen. aber darüber kann man sicherlich streiten, zumal ich da ein wenig vorbelastest bin. wenn ich auch nur schon den namen objekte in bezug auf rdms höre streueb sich mir die nackenhaare......

Ilja

[TobiasBuschi]

Hallo Ilja

Das geht auch mir so wenn ich von oodbms und solchem Zeugs lese.

Ich will nur Attribute von herkömmlichen Tabellen auf andere Tabellen vererben können, so wie ich es im Beispiel geschildert habe.

Und dann noch bei der Abfrage die vererbten Tabellen automatisch einbeziehen können.

Wäre für DB Hersteller technisch wahrscheinlich nicht kompliziert umsetzbar.
Und ich bin davon überzogen, dass das DIE Lüche in der IT ist :)

Gruss
TobiasBuschi

Gibt ein Konzept oder ein Standard der in einer Db vererben von Tabellen beschreibt?

Was meint Ihr?

meine ganz persönliche meingung dazu ist, zur zeit würde ich keine objektorientierten ansätze in das datendesign eines rdbms mit einbringen. aber darüber kann man sicherlich streiten, zumal ich da ein wenig vorbelastest bin. wenn ich auch nur schon den namen objekte in bezug auf rdms höre streueb sich mir die nackenhaare......

Ilja

[Ilja]

yo,

Ich will nur Attribute von herkömmlichen Tabellen auf andere Tabellen vererben können, so wie ich es im Beispiel geschildert habe.

Und dann noch bei der Abfrage die vererbten Tabellen automatisch einbeziehen können.

und genau das ist meiner meinung nach der quatsch, wo ich immer mit den entwicklern immer wieder ins streitgespräch komme, OOP <> RDBMS. mein tipp, und ich betone noch mal, dass dies nur meine meinung ist, würde ich so nicht vorgehen und das ganz schnell wieder vergessen.

Ilja

[TobiasBuschi]

Ilja

Ich denke ein RDBS ist in ihrer Natur schon Objekt-Orientiert eine
Tabelle ist der Bauplan also die Klasse und ein
Tupel ist eine Instanz dieses Bauplans also ein Objekt, ein ganz einfaches Objekt ohne Logik nur mit einfachen Eigenschaften.

Und jetzt will nur noch die Vererbung rein bringen,
das heisst ich will nur Attribute über mehrere Tabellen hinweg teilen.

Sozusagen will ich die relationale Datenbank mit meinem Objektorientierten Programmcode kompatibel machen.

Gruss
TobiasBuschi

[Ilja]

yo,

Und jetzt will nur noch die Vererbung rein bringen,
das heisst ich will nur Attribute über mehrere Tabellen hinweg teilen.

Sozusagen will ich die relationale Datenbank mit meinem Objektorientierten Programmcode kompatibel machen.

irgendwie kommt mir das wort "nur" spanisch vor. mein tipp, finger weg davon, aber jeder macht halt seine eigenen erfahrungen.

Ilja

[TobiasBuschi]

hi

irgendwie kommt mir das wort "nur" spanisch vor. mein tipp, finger weg davon, aber jeder macht halt seine eigenen erfahrungen.

Um deinem Rat, die Finger davon zu lassen, bringst du mir zu wenig Argumente, eigene Erfahrungen.
Du müsstest wenigstens meine Argumente vernichten.
Es macht mir den Anschein, dass du meine Idee gar nicht erst probierst zu verstehen, sondern aus Angst vor Komplexität (habe ich auch) die Augen verschliesst.

Nichts für ungut, aber ich werde die Idee weiter verfolgen.

schönes Wochenende
TobiasBuschi

[Ilja]

yo,

Du müsstest wenigstens meine Argumente vernichten.

ich muss gar nichts und es ist immer gut, wenn jeder selbst seine eigenen erfahrungen macht. vielleicht findest du ja wege und mittel dein vorhaben umzusetzen. du hast um rat und erfahrungen gefragt, ich habe dir meine gesagt.

aber noch ein paar hinweise für dich aus meiner sicht. grosse firmen mit klugen köpfen versuchen schon seit vielen jahren OO-Konzepte in die welt der Datenbanken zu integrieren, meiner meinung nach sind alle versuche bisher gescheitert. warum glaubst du da auf einmal eine lücke zu erkennen, die leicht umzusetzen ist ?

zum anderen werden in rdbms die entitäten anders als objekte in OOP modelliert. dabei geht es um abhängikeiten und ein drucker ist nun mal etwas anderes als ein monitor. das wären zwei getrennte entitäten. trennt man es nicht, wird man probleme bekommen, so kann zum beispiel ein drucker bei deinen modell die eigenschaften eines monitors besitzen, etc.

Ilja

[Vinzenz Mai]

Hallo,

CREATE TABLE product {
  id int autoincrement
  name varchar 255
  preis float
}

CREATE TABLE monitor EXTENDS product {

product_id          -- Verweis auf die Produkt-ID

gewicht int
  resolution_x int
  resolution_y int

-- product_id ist Primärschlüssel der Tabelle
    -- und gleichzeitig Fremdschlüssel auf id der Tabelle product

}

d.h. eine 1:1-Beziehung, gleiches für Deine Drucker.

CREATE TABLE drucker EXTENDS product {   /// <------ EXTENDS
  gewicht int
  auflösung int
  geschwindigkeit int
}

Mit einer UNION der entsprechenden Joins bekommst Du Dein Abfrageergebnis.

[code lang=sql]
SELECT
    id,
    name,
    gewicht,
    'monitor' __entity
FROM
    product p
INNER JOIN
    monitor m
ON
    p.id = m.product_id
UNION
SELECT
    id,
    name,
    gewicht,
    'drucker' __entity
FROM
    product p
INNER JOIN
    drucker d
ON
    p.id = d.product_id

id | name            | gewicht   | __entity__

2  | EIZO Bildschirm | 4         | monitor
4  | HP Bildschirm   | 3         | monitor
5  | DELL Bildschirm | 3         | monitor
8  | BElinea Bildsc. | 5         | monitor
1  | HP Drucker      | 2         | drucker
89 | EPSON DRUCKER 2 | 1         | drucker

Du kannst nun die WHERE-Klausel in die beiden SELECTS einbringen und bekommst das gewünschte Ergebnis.

Ein solches Konzept fehlt mir extrem!

Es ist vorhanden.

Freundliche Grüße

Vinzenz

[TobiasBuschi]

Hallo Vinzenz

Besten Dank!!!

Habe ich bis jetzt nicht gekannt. Das muss ich erst mal verdauen... :)

Nutzt du das Oft?

Zu meinem Ansatz:
Ich denke wenn die Datenbank weiss welche Vererbungen bestehen
und ihre interne Struktur darauf ausgelegt ist
wird eine solche Abfrage schneller, da die Verknüpfungen nicht gesucht
werden müssen. Zusätzlich der Nebeneffekt dass die Abfrage massiv einfacher aussieht.

Wäre mein dargestellter Ansatz deiner Meinung nach sinnvoll?

Gruss
TobiasBuschi

[TobiasBuschi]

Keine Datenbankspezialisten mehr die sich dazu äussern wollen? :)