Ein Flohmarktbetreiber erzeugt gleichartige Events mit verschiedem Datum.
Dein eigentliches Problem ist nicht die Abfrage bzw. der Eintrag sondern die Normalisierung.
Für offenbar wiederkehrende Events teile die Tabelle:
Bisher:
spalte | spalte | spalte | spalte | spalte |
---|---|---|---|---|
id | datum | ort | event | sonstwas |
Danach:
Tabelle: Termine
spalte | spalte | spalte | spalte |
---|---|---|---|
termin_id | datum | event_id | ort_id |
Tabelle: Events
spalte | spalte | spalte |
---|---|---|
event_id | event | sonstwas |
Tabelle Orte: (Wer behauptet denn, dass ein Betreiber nicht Flohmärkte an verschiedenen Orten organisieren kann?)
spalte | spalte | spalte |
---|---|---|
ort_id | ort | sonstwas |
Möglicherweise willst Du auch noch eine Tabelle, in welcher Du Ereignis-Typen einem Benutzer zuordnest, z.B. damit dieser „seine“ Ereignis-Typen einfach im Formular auswählen kann.
Nun sind neue Felder dazu gekommen, die sind in der Kopie nicht dabei.
Aus welchem Grund füllst Du die Tabelle(n)? Weil Du es dem Anwender ermöglichen willst, vermittels einer Anwendung Zeug einzutragen? Flexibilität kannst Du hier erreichen, in dem Spalten der Tabelle(n), die womöglich nicht gefüllt werden, mit passenden DEFAULT
-Werten besetzt werden.
Hier ein Beispiel aus dem Handbuch:
CREATE TABLE t1 (
i INT DEFAULT -1,
c VARCHAR(10) DEFAULT '',
price DOUBLE(16,2) DEFAULT 500
);
(Das geht auch nachträglich mit ALTER TABLE
.)
verfügt die Anwendung also ein
INSERT INTO t1 ( i, c )
VALUES ( 3, "foo" )
oder
INSERT INTO `t1`
SET
`i` = 3,
`c` = "foo"
... dann steht sodann
i | c | price |
---|---|---|
3 | foo | 500.00 |
drin.