DBMS mit mehreren Namen pro Spalte?

[BLUESCREEN3D]

Gibt es DBMS bei denen man einzelnen Spalten von Tabellen mehrere Namen geben kann, so dass man über verschiedene Namen auf die selbe Spalte zugreifen kann?

PS: Ich will kein SELECT `bla` AS `blubb`

[michael.sprick]

also in Oracle kannst Du ja z.B. "views" auf eine Tabelle erzeugen. In dieser View hast Du dann die Möglichkeit, Deine virtuellen Spalten beliebig zu benennen.
Aber soweit ich weiß, kannst Du dort auch nur einen Namen vergeben - nicht mehrere Aliase.

Was hast Du denn genau vor? Evtl. gibts eine andere Lösung...

[elrond]

ich denke auch, dass view die lösung ist

[BLUESCREEN3D]

Was hast Du denn genau vor? Evtl. gibts eine andere Lösung...
Es geht um Spalten, die abhängig von anderen Werten verschiedene Daten enthalten können.

Und diese Spalten immer mit "bla_or_blubb_or_sonstwas" zu benennen, um alles im Namen zu haben ist sehr nervig...

[mwanaheri]

Das klingt mir sehr nach mangelnder Normalisierung. Bist du sicher, dass du ein sinnvolles Design hast?

[BLUESCREEN3D]

Das klingt mir sehr nach mangelnder Normalisierung. Bist du sicher, dass du ein sinnvolles Design hast?
Daran sollte es eigentlich nicht liegen.

Mal ein Beispiel:

In einer Tabelle, die Benutzeraccounts enthält gibt es zwei Spalten von denen die eine den Freischaltcode des Accounts enthält und die andere angibt, bis wann der Account gesperrt ist. Da nicht freigeschaltete Accounts unbrauchbar sind braucht man die auch nicht Sperren zu können.
Kurz: Ein Account wird nie gleichzeitig einen Freischaltcode und eine Sperrzeit brauchen, also kann man die für die beiden Werte auch eine Spalte nehmen (ob der Account gerade gesperrt oder noch nicht freigeschaltet ist steht in einem Bitset in einer anderen Spalte).

[mwanaheri]

Daran sollte es eigentlich nicht liegen.

Mal ein Beispiel:

In einer Tabelle, die Benutzeraccounts enthält gibt es zwei Spalten von denen die eine den Freischaltcode des Accounts enthält und die andere angibt, bis wann der Account gesperrt ist. Da nicht freigeschaltete Accounts unbrauchbar sind braucht man die auch nicht Sperren zu können.
Kurz: Ein Account wird nie gleichzeitig einen Freischaltcode und eine Sperrzeit brauchen, also kann man die für die beiden Werte auch eine Spalte nehmen (ob der Account gerade gesperrt oder noch nicht freigeschaltet ist steht in einem Bitset in einer anderen Spalte).

Es tut dir aber doch auch nicht weh, wenn du dafür zwei Spalten nimmst, zumal die beiden Angaben ja ihrer Natur nach unterschiedliche Datentypen sind, die du dann direkt als Spaltentyp verwenden kannst. Für den Preis einer zusätzlichen Spalte sparst du dir also Fallunterscheidung und Typanalyse/Typumwandlung. Meinst du nicht, das sei eine Spalte wert? Anders herum gefragt: Was würde es denn nötig machen, beide Angaben in eine Spalte zu pressen?

[Jasper]

Kurz: Ein Account wird nie gleichzeitig einen Freischaltcode und eine Sperrzeit brauchen, also kann man die für die beiden Werte auch eine Spalte nehmen (ob der Account gerade gesperrt oder noch nicht freigeschaltet ist steht in einem Bitset in einer anderen Spalte).

das ist aber kein gutes design. damit mixt du zwei attribute, die vom datentyp und der bedeutung nichts gemeinsam haben.
die anforderung "niemals freischaltcode und sperrzeit gleichzeitig" definiert man normalerweise über constraints.


-j

[BLUESCREEN3D]

Ich lege natürlich nur Spalten zusammen, die eh den gleichen Datentyp haben.


Was würde es denn nötig machen, beide Angaben in eine Spalte zu pressen?
Unbedingt nötig ist es natürlich nicht, spart aber Speicherplatz.


damit mixt du zwei attribute, die vom (...) der bedeutung nichts gemeinsam haben.
Deshalb würde ich der Spalte ja gerne zwei Namen geben.


die anforderung "niemals freischaltcode und sperrzeit gleichzeitig" definiert man normalerweise über constraints.
Kannst du das genauer erläutern?

[mwanaheri]

Kannst du das genauer erläutern?

Ich habe es gerade mal schnell durchgespielt (Postgresql). Die folgende Tabelle erlaubt es nicht, ein Sperrdatum einzugeben, wenn ein Freischaltcode eingetragen ist:

CREATE TABLE excludeone
(
id serial NOT NULL,
freischalt varchar(10) DEFAULT ''::character varying,
block date,
CONSTRAINT primkey PRIMARY KEY (id),
CONSTRAINT exklusion CHECK (freischalt::text = ''::text OR block IS NULL)
)

Ich nehme mal an, varchar und Date sind brauchbare typen für Freischaltcode und Sperrdatum. Ich habe hier gegen '' beim Freischaltcode getestet, sinnvoller ist es wahrscheinlich, das auf null zu setzen und auch dagegen zu testen. Jasper kennt vielleicht noch einen eleganteren Weg. Bin nicht wirklich fit bei constraints...

[Jasper]

und hier die oracle-version:

create table bla (
freischaltcode number,
sperrdatum date,
check(not(freischaltcode is not null and sperrdatum is not null)));

falls mindestens 1 spalte gesetzt sein muss, die logik einfach in ein XOR ändern.


-j

[BLUESCREEN3D]

Das klingt interessant, aber anscheinend kann mein in diesem Fall verwendetes DBMS (MySQL) das nicht :/

Zumindest finde ich im Manual nichts dazu.

Da fragt man sich doch, wie es dazu kam, dass MySQL verbreiteter ist als PostgreSQL?

[Jasper]

das ganze geht auch mit trigger, die hat mysql glaube ich:

create table bla (
freischaltcode number,
sperrdatum date);

create or replace trigger check_bla
before insert or update on bla
for each row
begin
if :new.freischaltcode is not null and
:new.sperrdatum is not null then
raise_application_error(-20000, 'freischaltcode + sperrdatum = no-go');
end if;
end;

ist wieder oracle-syntax, muss also garantiert angepasst werden.
zu postgresql vs. mysql: es setzt sich leider nicht immer das bessere durch.


-j