[mysql] samengestelde primary key

[Verwijderd]

reserveringsnr - kamernr - begindatum - einddatum
primary key (reserveringsnr,kamernr)

wat dus in feite zou moeten kunnen is de volgende waarden invoeren:

rnr-knr - begindatum - einddatum

1 - 101 - 2002-05-05 - 2002-05-06
2 - 101 - 2002-05-05 - 2002-05-06

duplicate entry '101-2002-05-05-2002-05-06' for key 2

MAAR dat kan toch helemaal niet want alleen de combinatie van reserveringsnr EN kamernr moet uniek zijn en die begin en einddatum hebben dr niks mee te maken en zijn ook niet unique of wat dan ook

[Verwijderd]

Geen problemen mee hoor...

code:

mysql> describe test;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| rnr   | int(11) | | PRI | 0    |   |
| knr   | int(11) | | PRI | 0    |   |
| begin | date    | YES  |     | NULL    |   |
| eind  | date    | YES  |     | NULL    |   |
+-------+---------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> select * from test;
+-----+-----+------------+------------+
| rnr | knr | begin | eind   |
+-----+-----+------------+------------+
|   1 | 101 | 2002-05-05 | 2002-05-06 |
|   2 | 101 | 2002-05-05 | 2002-05-06 |
+-----+-----+------------+------------+
2 rows in set (0.00 sec)

mysql>

[Verwijderd]

+----------------+---------+------+-----+------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+---------+------+-----+------------+-------+
| RESERVERINGSNR | int(10) | | PRI | 0 | |
| KAMERNR | int(3) | | PRI | 0 | |
| AANKOMSTDATUM | date | | | 0000-00-00 | |
| VERTREKDATUM | date | | | 0000-00-00 | |
+----------------+---------+------+-----+------------+-------+
4 rows in set (0.00 sec)

mysql> insert into kamerreservering values('2','104','2002-05-05','2002-05-09');

Query OK, 1 row affected (0.00 sec)

mysql> insert into kamerreservering values('3','104','2002-05-05','2002-05-09');

ERROR 1062: Duplicate entry '104-2002-05-05-2002-05-09' for key 2

Waarom bij mij dan wel ?

[mulder]

Geeft
mysql> insert into kamerreservering values('2','105','2002-05-05','2002-05-09');
ook een error?

[Verwijderd]

nee

+----------------+---------+---------------+--------------+
| RESERVERINGSNR | KAMERNR | AANKOMSTDATUM | VERTREKDATUM |
+----------------+---------+---------------+--------------+
| 1 | 104 | 2002-05-05 | 2002-05-08 |
| 2 | 104 | 2002-05-05 | 2002-05-09 |
| 3 | 102 | 2002-05-05 | 2002-05-09 |
| 2 | 105 | 2002-05-05 | 2002-05-09 |
+----------------+---------+---------------+--------------+
4 rows in set (0.00 sec)

[Verwijderd]

mmh.. ik blijf erbij:

code:

mysql> insert into test values ('3', '102', '2002-05-05', '2002-05-06');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values ('4', '102', '2002-05-05', '2002-05-06');
Query OK, 1 row affected (0.00 sec)

Dit was m'n CREATE TABLE:

code:

create table test (rnr int not null, knr int not null, begin date, eind date, primary key (rnr, knr));

Versie van MySQL wel interessant? Dit is

code:

Server version:    3.23.49-nt

[Verwijderd]

AARGH en dit weer wel

+----------------+---------+---------------+--------------+
| RESERVERINGSNR | KAMERNR | AANKOMSTDATUM | VERTREKDATUM |
+----------------+---------+---------------+--------------+
| 1 | 104 | 2002-05-05 | 2002-05-08 |
| 2 | 104 | 2002-05-05 | 2002-05-09 |
| 3 | 102 | 2002-05-05 | 2002-05-09 |
| 2 | 105 | 2002-05-05 | 2002-05-09 |
+----------------+---------+---------------+--------------+
4 rows in set (0.00 sec)

mysql> insert into kamerreservering values('3','104','2002-05-05','2002-05-09');

ERROR 1062: Duplicate entry '104-2002-05-05-2002-05-09' for key 2

[Glimi]

Zet uns geen quotes om niet strings neer (je int's dus), die horen daar niet. Of dat de boel gaat oplossen weet ik niet

[edit]Volgens mij wel, want hij geeft ook die Key_2 als een lange string aan

[Verwijderd]

HEEJ JA
haha verdorie

bedankt !! (maar wel een beetje vaag van mysql zeg)

[dusty]

Bij de laatste keer dat ik ooit heb gewerkt met reserverings nummers was het toevallig dat de reserverings nummer altijd uniek was. Iets met als iemand aan de balie staat, wil je graag weten welke reservering het exact is, en niet nog een keer vragen "Welk kamer nummer had u?" dat moet je al vanuit de reserverings nummer moeten kunnen achterhalen (anders heb je natuurlijk niets aan een reserverings nummer)

Met Andere Woorden: Een samengestelde primary key is hier onzin, en brengt de betrouwbaarheid van je gegevens in gevaar.

[Ignoramus]

Op dinsdag 28 mei 2002 23:54 schreef dusty het volgende:
Bij de laatste keer dat ik ooit heb gewerkt met reserverings nummers was het toevallig dat de reserverings nummer altijd uniek was. Iets met als iemand aan de balie staat, wil je graag weten welke reservering het exact is, en niet nog een keer vragen "Welk kamer nummer had u?" dat moet je al vanuit de reserverings nummer moeten kunnen achterhalen (anders heb je natuurlijk niets aan een reserverings nummer)

Met Andere Woorden: Een samengestelde primary key is hier onzin, en brengt de betrouwbaarheid van je gegevens in gevaar.

En als je nou eens meerdere kamers tegelijk wilt reseveren?

[Jelmer]

Ik heb hier pas ook mee gewerkt en kan je vertellen dat het mogelijk is!!

Zorg dat je even een redelijk nieuwe MySQL server hebt (eentje die MyISAM tabellen kan aanmaken, in iedergeval de versie die bij Debian Potato zit kan het niet). Vervolgens doe je dit:

code:

CREATE TABLE Factuur (
  factuurID int(10) unsigned NOT NULL auto_increment,
  factuurIDJaar int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (factuurIDJaar,factuurID)
) TYPE=MyISAM;

Zoals je ziet moet je het auto field als laatste opgeven en dan gaat alles perfect!!

code:

+-----------+---------------+
| factuurID | factuurIDJaar |
+-----------+---------------+
|      1 |      2002 |
|      2 |      2002 |
|      1 |      2003 |
+-----------+---------------+

Succes ermee!


(hmm, 'lichtelijk' te laat zie ik nu pas, maar misschien toch nog handig voor als iemand ooit nog eens dit topic met de search omhoog vist)

[dusty]

Op woensdag 29 mei 2002 00:00 schreef Ignoramus het volgende:
[..]
En als je nou eens meerdere kamers tegelijk wilt reseveren?

Die hebben dan normaal allemaal dezelfde begin en eind datum. Zijn ze verschillend krijg je in dat geval bij heel veel (zo niet alle) hotels gewoon twee verschillende reserveringsnummers.

[Ignoramus]

Is ook een mogelijkheid. Alleen als je nog andere tabellen hebt die afhankelijk zijn van kamernummer of reserveringsnummer wordt het lastig.

Op woensdag 29 mei 2002 00:17 schreef dusty het volgende:

[..]

Die hebben dan normaal allemaal dezelfde begin en eind datum. Zijn ze verschillend krijg je in dat geval bij heel veel (zo niet alle) hotels gewoon twee verschillende reserveringsnummers.

[Verwijderd]

Ik snap niet wat het probleem is met de modellering hiervan. Een reservering is gewoon een order, en de kamers die worden gereserveerd (incl. welk hotel, welk kamernummer, vanaf/tot datum, etc) zijn order lines.

In de reservering tabel is dus het reserveringsnummer PK, in de orderlines (of reserveringsitems) tabel is een reserveringsitemnummer de key, met reserveringnummer als FK. Een kamernummer is een betekenisvol gegeven en zou dus niet gebruikt moeten worden als (deel van) een PK.

edit:

Overigens is het nog veel netter om in een reservering i.p.v. een kammernummer een kamertype vast te leggen (van een gekozen prijsklasse), tenzij een klant expliciet een specifieke kamer iets. Dit betekent dat je, onafhankelijk hiervan een beschikbaarheidssysteem moet bijhouden, maar dat maakt het wel flexibeler.

Stel dat een kamer afbrandt, of een klant die later komt heeft een specifieke voorkeur voor die kamer, dan kan je in het beschikbaarheidssysteem nog makkelijk in schuiven zonder reserveringen te hoeven aanpassen. Zo doen veel luchtvaartmaatschappijen het ook.

[Janoz]

Op woensdag 29 mei 2002 00:24 schreef Ignoramus het volgende:
Is ook een mogelijkheid. Alleen als je nog andere tabellen hebt die afhankelijk zijn van kamernummer of reserveringsnummer wordt het lastig.
[..]

Als bij 1 reservering meerdere kamers horen, dan is dit een 1:N relatie. Dit los je niet op door een 'dubbele primairy key', maar door een extra tabel.