DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> 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:
| 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:
~~~SQL
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
~~~SQL
INSERT INTO t1 ( i, c )
VALUES ( 3, "foo" )
~~~
oder
~~~SQL
INSERT INTO `t1`
SET
`i` = 3,
`c` = "foo"
~~~
... dann steht sodann
| i | c | price |
| --- | --- | --- |
| 3 | foo | 500.00 |
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> 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:
| 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:
~~~SQL
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
~~~SQL
INSERT INTO t1 ( i, c )
VALUES ( 3, "foo" )
~~~
oder
~~~SQL
INSERT INTO `t1`
SET
`i` = 3,
`c` = "foo"
~~~
... dann steht sodann
| i | c | price |
| --- | --- | --- |
| 3 | foo | 500.00 |
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> 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:
| spalte | spalte | spalte |
| --- | --- | --- |
| ort_id | ort | sonstwas |
> 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:
~~~SQL
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
~~~SQL
INSERT INTO t1 ( i, c )
VALUES ( 3, "foo" )
~~~
oder
~~~SQL
INSERT INTO `t1`
SET
`i` = 3,
`c` = "foo"
~~~
... dann steht sodann
| i | c | price |
| --- | --- | --- |
| 3 | foo | 500.00 |
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> 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:
| spalte | spalte | spalte |
| --- | --- | --- |
| ort_id | ort | sonstwas |
> 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:
~~~SQL
CREATE TABLE t1 (
i INT DEFAULT -1,
c VARCHAR(10) DEFAULT '',
price DOUBLE(16,2) DEFAULT 500
);
~~~
verfügt die Anwendung also ein
~~~SQL
INSERT INTO t1 ( i, c )
VALUES ( 3, "foo" )
~~~
oder
~~~SQL
INSERT INTO `t1`
SET
`i` = 3,
`c` = "foo"
~~~
... dann steht sodann
| i | c | price |
| --- | --- | --- |
| 3 | foo | 500.00 |
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> 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:
| spalte | spalte | spalte |
| --- | --- | --- |
| ort_id | ort | sonstwas |
> 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:
~~~SQL
CREATE TABLE t1 (
i INT DEFAULT -1,
c VARCHAR(10) DEFAULT '',
price DOUBLE(16,2) DEFAULT 500
);
~~~
verfügt die Anwendung also ein
~~~SQL
INSERT INTO t1 (i, c) values (3, "foo")
~~~
oder
~~~SQL
INSERT INTO `t1`
SET
`i` = 3,
`c` = "foo"
~~~
dann steht sodann
| i | c | price |
| --- | --- | --- |
| 3 | foo | 500.00 |
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> 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:
| spalte | spalte | spalte |
| --- | --- | --- |
| ort_id | ort | sonstwas |
> 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:
~~~SQL
CREATE TABLE t1 (
i INT DEFAULT -1,
c VARCHAR(10) DEFAULT '',
price DOUBLE(16,2) DEFAULT 500
);
~~~
verfügt die Anwendung also ein
~~~SQL
INSERT INTO t1 (i, c) values (3, "foo")
~~~
dann steht danach
| i | c | price |
| --- | --- | --- |
| 3 | foo | 500.00 |
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> Ein Flohmarktbetreiber erzeugt gleichartige Events mit verschiedem Datum.
Dein eigentliches Problem ist nicht die Abfrage bzw. der Eintrag sondern die Normalisierung.
Für 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:
| spalte | spalte | spalte |
| --- | --- | --- |
| ort_id | ort | sonstwas |
> 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:
~~~SQL
CREATE TABLE t1 (
i INT DEFAULT -1,
c VARCHAR(10) DEFAULT '',
price DOUBLE(16,2) DEFAULT 500
);
~~~
verfügt die Anwendung also ein
~~~SQL
INSERT INTO t1 (i, c) values (3, "foo")
~~~
dann steht danach
| i | c | price |
| --- | --- | --- |
| 3 | foo | 500.00 |
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> Ein Flohmarktbetreiber erzeugt gleichartige Events mit verschiedem Datum.
Dein eigentliches Problem ist nicht die Abfrage bzw. der Eintrag sondern die Normalisierung.
Für 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:
| spalte | spalte | spalte |
| --- | --- | --- |
| ort_id | ort | sonstwas |
> 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:
~~~SQL
CREATE TABLE t1 (
i INT DEFAULT -1,
c VARCHAR(10) DEFAULT '',
price DOUBLE(16,2) DEFAULT 0.00
);
~~~
verfügt die Anwendung also ein
~~~SQL
INSERT INTO t1 (i, c) values (3, "foo")
~~~
dann steht danach
| i | c | price |
| --- | --- | --- |
| 3 | foo | 0.00 |
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> Ein Flohmarktbetreiber erzeugt gleichartige Events mit verschiedem Datum.
Dein eigentliches Problem ist nicht die Abfrage bzw. der Eintrag sondern die Normalisierung.
Für Wiederkehrende Events teile die Tabelle:
Bisher:
| id | datum | ort | event | sonstwas |
Danach:
Tabelle: Termine
| termin_id |datum | event_id | ort_id |
Tabelle: Events
| event_id |event | sonstwas |
Tabelle Orte:
| ort_id | ort | sonstwas |
> 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:
~~~SQL
CREATE TABLE t1 (
i INT DEFAULT -1,
c VARCHAR(10) DEFAULT '',
price DOUBLE(16,2) DEFAULT 0.00
);
~~~
verfügt die Anwendung also ein
~~~SQL
INSERT INTO t1 (i, c) values (3, "foo")
~~~
dann steht danach
| i | c | price |
| 3 | foo| 0.00
drin.
DB Tabellenzeile kopieren
bearbeitet von Raketenwilli> Ein Flohmarktbetreiber erzeugt gleichartige Events mit verschiedem Datum.
Dein eigentliches Problem ist nicht die Abfrage bzw. der Eintrag sondern die Normalisierung.
Für Wiederkehrende Events teile die Tabelle:
Bisher:
|id|datum|ort|event|sonstwas|
Danach:
Tabelle: Termine
|termin_id|datum|event_id|ort_id|
Tabelle: Events
|event_id|event|sonstwas|
Tabelle Orte:
|ort_id|ort|sonstwas|
> 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:
~~~SQL
CREATE TABLE t1 (
i INT DEFAULT -1,
c VARCHAR(10) DEFAULT '',
price DOUBLE(16,2) DEFAULT 0.00
);
~~~
verfügt die Anwendung also ein
~~~SQL
INSERT INTO t1 (i, c) values (3, "foo")
~~~
dann steht danach
|i|c|price|
|3|foo|0.00
drin.