9
MySQL unter phpMyAdmin richtig vorbereiten?
Hallo,
ich möchte eine MySQL Datenbank nach diesem Schema aufbauen:
ID (auto increment, aber Zahlen manuell änderbar)
Aufgabe (Name der Aufgabe; (varchar(25))
Deadline (Bis wann muss die Aufabe erledigt sein? (datetime))
Status (Erledigt oder offen / 0/1)
wannErledigt (Anfangs kein/leerer Wert, _nachdem_ Status von 0 auf 1 gesetzt wurde, soll hier der zugehörige Zeitpunkt stehen)
CREATE TABLE `tasks`.`bathroom` ( `id` INT(100) BINARY NOT NULL AUTO_INCREMENT COMMENT 'bathroom_id' , `task` VARCHAR(25) NOT NULL COMMENT 'bathroom_task' ,
`deadline` DATETIME NOT NULL COMMENT 'bathroom_deadline' , `status` INT(2) NOT NULL COMMENT 'bathroom_status(0=todo,1=done)' , `done` DATETIME on update
CURRENT_TIMESTAMP NOT NULL COMMENT 'bathroom_done' ) ENGINE = InnoDB;
funktioniert nicht.
Ich habe nicht viel Ahnung mit MySQL Befehlen an sich (weshalb ich auch phpMyAdmin zum Datenbankaufbau nutze!) und weiß nicht, wo der Fehler liegt.
Könnt Ihr mir weiterhelfen?
Danke & LG
ich möchte eine MySQL Datenbank nach diesem Schema aufbauen:
ID (auto increment, aber Zahlen manuell änderbar)
Aufgabe (Name der Aufgabe; (varchar(25))
Deadline (Bis wann muss die Aufabe erledigt sein? (datetime))
Status (Erledigt oder offen / 0/1)
wannErledigt (Anfangs kein/leerer Wert, _nachdem_ Status von 0 auf 1 gesetzt wurde, soll hier der zugehörige Zeitpunkt stehen)
CREATE TABLE `tasks`.`bathroom` ( `id` INT(100) BINARY NOT NULL AUTO_INCREMENT COMMENT 'bathroom_id' , `task` VARCHAR(25) NOT NULL COMMENT 'bathroom_task' ,
`deadline` DATETIME NOT NULL COMMENT 'bathroom_deadline' , `status` INT(2) NOT NULL COMMENT 'bathroom_status(0=todo,1=done)' , `done` DATETIME on update
CURRENT_TIMESTAMP NOT NULL COMMENT 'bathroom_done' ) ENGINE = InnoDB;
funktioniert nicht.
Ich habe nicht viel Ahnung mit MySQL Befehlen an sich (weshalb ich auch phpMyAdmin zum Datenbankaufbau nutze!) und weiß nicht, wo der Fehler liegt.
Könnt Ihr mir weiterhelfen?
Danke & LG
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 277542
Url: https://administrator.de/contentid/277542
Printed on: April 20, 2024 at 02:04 o'clock
9 Comments
Latest comment
Hi,
MySQL sagt doch eh recht ausfürlich was ihm nicht gefällt. Was spricht es denn?
sg Dirm
MySQL sagt doch eh recht ausfürlich was ihm nicht gefällt. Was spricht es denn?
sg Dirm
Moin carl7n,
schneller würde es in der Tat gehen, wenn du die Fehlermeldung/den SQL-Errorcode posten würdest.
Dann könnten wir auch einen nutznutzigen Praktikanten oder Teamleiter mit einer Suchmaschinen-Recherche losjagen.
Anyway...
Zumindest 2 mögliche Klemmer sprangen mir ins Auge:
b) das "NOT NULL" gehört eigentlich vor die "ON UPDATE"-Klausel
c) das Feld ist NOT NULL, hat aber keinen Default (bzw. nur beim UPDATE-Fall)
Also wäre dann (da ein leeres Feld ausgeschlossen ist) das für deine Zwecke passendste entweder
.
.
Im ganzen Satz also die Anpassungen:
Grüße
Biber
schneller würde es in der Tat gehen, wenn du die Fehlermeldung/den SQL-Errorcode posten würdest.
Dann könnten wir auch einen nutznutzigen Praktikanten oder Teamleiter mit einer Suchmaschinen-Recherche losjagen.
Anyway...
CREATE TABLE `tasks`.`bathroom`
( `id` INT(100) BINARY NOT NULL AUTO_INCREMENT -COMMENT 'bathroom_id'
, `task` VARCHAR(25) NOT NULL COMMENT 'bathroom_task'
, `deadline` DATETIME NOT NULL COMMENT 'bathroom_deadline'
, `status` INT(2) NOT NULL COMMENT 'bathroom_status(0=todo,1=done)'
, `done` DATETIME on update CURRENT_TIMESTAMP NOT NULL COMMENT 'bathroom_done'
) ENGINE = InnoDB;- die Definition von id INT(100) ist Bullshit - wieso soll denn ein Integer in der Breite 100 Ziffern angezeigt werden?
- die Definition von "done" ist mehrfach fragwürdig.
b) das "NOT NULL" gehört eigentlich vor die "ON UPDATE"-Klausel
c) das Feld ist NOT NULL, hat aber keinen Default (bzw. nur beim UPDATE-Fall)
Also wäre dann (da ein leeres Feld ausgeschlossen ist) das für deine Zwecke passendste entweder
.
, ...done timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP -oder-.
, ...done timestamp ON UPDATE CURRENT_TIMESTAMP // also NULLS ALLOWEDIm ganzen Satz also die Anpassungen:
CREATE TABLE tasks.bathroom
( id INT NOT NULL AUTO_INCREMENT -COMMENT 'bathroom_id'
, task VARCHAR(25) NOT NULL COMMENT 'bathroom_task'
, deadline DATETIME NOT NULL COMMENT 'bathroom_deadline'
, status INT(2) NOT NULL COMMENT 'bathroom_status(0=todo,1=done)'
, done TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP COMMENT 'bathroom_done'
) ENGINE = InnoDB;Grüße
Biber
Zitat von @Biber:
Moin carl7n,
schneller würde es in der Tat gehen, wenn du die Fehlermeldung/den SQL-Errorcode posten würdest.
Dann könnten wir auch einen nutznutzigen Praktikanten oder Teamleiter mit einer Suchmaschinen-Recherche losjagen.
Moin carl7n,
schneller würde es in der Tat gehen, wenn du die Fehlermeldung/den SQL-Errorcode posten würdest.
Dann könnten wir auch einen nutznutzigen Praktikanten oder Teamleiter mit einer Suchmaschinen-Recherche losjagen.
Sry. phpMyAdmin hat mir den Fehler immer nur als Popup ausgegeben, welches beim Markieren (bevor ich kopieren konnte) wieder verschwunden war.
CREATE TABLE tasks.bathroom
( id INT NOT NULL AUTO_INCREMENT COMMENT 'bathroom_id'
, task VARCHAR(25) NOT NULL COMMENT 'bathroom_task'
, deadline DATETIME NOT NULL COMMENT 'bathroom_deadline'
, status INT(2) NOT NULL COMMENT 'bathroom_status(0=todo,1=done)'
, done TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP COMMENT 'bathroom_done'
) ENGINE = InnoDB
MySQL meldet: Dokumentation
meldet
#1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key
100 war natürlich Quatsch, da hätte wohl eine 3 gereicht ^^ Ist mir nun auch aufgefallen.
na okay, den kleinen Fehler bekommen wir schnell weg mit einer Zusatzzeile.
Grüße
Biber
CREATE TABLE tasks.bathroom
( id INT NOT NULL AUTO_INCREMENT COMMENT 'bathroom_id'
, task VARCHAR(25) NOT NULL COMMENT 'bathroom_task'
, deadline DATETIME NOT NULL COMMENT 'bathroom_deadline'
, status INT(2) NOT NULL COMMENT 'bathroom_status(0=todo,1=done)'
, done TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP COMMENT 'bathroom_done'
, PRIMARY KEY (ID)
) ENGINE = InnoDBGrüße
Biber
Vielen Dank für die Hilfe!
Ich merke gerade, dass ein paar Dinge doch nicht ganz durchdacht ... "deadline" passt als DATETIME insofern gar nicht, dass es sich jede Woche wiederholt. Wie löse ich das am Besten? Einfach den Tag (1-7) angeben und die Uhrzeit einmal manuell (z.B. in dem Script, welches die DB abfragt) hinterlegen? Oder geht das "eleganter"?
Ich merke gerade, dass ein paar Dinge doch nicht ganz durchdacht ... "deadline" passt als DATETIME insofern gar nicht, dass es sich jede Woche wiederholt. Wie löse ich das am Besten? Einfach den Tag (1-7) angeben und die Uhrzeit einmal manuell (z.B. in dem Script, welches die DB abfragt) hinterlegen? Oder geht das "eleganter"?
Moin carln7n,
it depends...
Dazu müssten wir wissen, was du da überhaupt zusammenschroten willst.
Oder - im IT-Slang ausgedrückt, die Anforderungen müssen definiert sein.
Wenn das Ganze so ein Putzplan für eure WG werden soll, weil da irgendein Frischling direkt von Mami zu euch gezogen ist und ohne klare Strukturen nicht klar kommt, dann...
Grüße
Biber
it depends...
Dazu müssten wir wissen, was du da überhaupt zusammenschroten willst.
Oder - im IT-Slang ausgedrückt, die Anforderungen müssen definiert sein.
Wenn das Ganze so ein Putzplan für eure WG werden soll, weil da irgendein Frischling direkt von Mami zu euch gezogen ist und ohne klare Strukturen nicht klar kommt, dann...
- Würde ich einmalig mit einem INSERT-Statement die Datensätze für die nächsten 2 Monate anlegen (die Termine lassen sich berechnen, Status- und Done-Werte sind bekannt.
- und ich würde überlegen, ob denn die Uhrzeit der Erledigung wichtig ist oder das Datum ausreicht also bei DONE doch DATETIME wie in deinem ersten Ansatz.
- und überlegen, ob es flexibler wird, wenn zusätzlich zu dem definierten "Task" noch ein "Name" zugeordnet werden soll - also der, der es tun soll bzw. der, der es auf "done" gesetzt hat. Denn im Moment ist es ja nur auswertbar, wann welche Tasks in welchem Status sind, aber nicht, wen man deshalb verhauen soll.
Grüße
Biber
Hehe, ich glaube eher, ich bin derjenige, der hier die klaren Strukturen will ;) Aber mehr dazu unten.
Ich definiere einfach mal die Anforderungen:
Haushaltsplan für 2 Gruppen. Gruppe 1 erledigt in ungeraden Wochen die Tasks der Tage 1,3,5,7 Gruppe zwei entsprechend 2,4,6; in geraden Wochen tauschen die Gruppen die Tasks.
Ob ich nun für jeden Raum eine eigene Tabelle festlegen, oder alles in eine schreiben soll, ist letztendlich egal; sobald alle Tasks einmal festgelegt sind, wird sich an dem Grundgerüst der Tabelle vermutlich wenig ändern. Ggf. könnte man unregelmäßigere Tasks (Gartenarbeit, Aussortieren von Schränken, whatever???) in eine eigene Tabelle auslagern.
Die Deadline muss innerhalb der Tabelle nicht unbedingt eine genaue Uhrzeit haben; das Script, welches die Tabelle letztendlich ausliest, kann das selbst vornehmen und ggf. Alarm schlagen (nette Version: per E-Mail; nicht so nette Version: Jabber, E-Mail, SMS, ggf. automatisierte Sprachmitteilung per Asterisk
), wenn die Tasks zu bestimmten Uhrzeiten nicht erledigt sind.
Der Ansatz, wer welchen Task wann erledigt hat, ist gut. Allerdings hatte ich es mir so vorgestellt, dass irgendwo ein Tablett hängt, welches alle offenen und erledigten Tasks in einer Tabelle (PHP sollte reichen?) anzeigt. Sobald jemand seinen Task erledigt hat, kann sie oder er dort kurz klicken und der Task wird als erledigt markiert. Das Tablett soll zentral hängen und ohne spezifische Userzuordnung klarkommen; ob Person A oder B von Gruppe 1 oder C oder D von Gruppe 2 den entsprechenden Task nun erledigt haben, ist somit nicht nachvollziehbar.
_Wann_ jemand bzw. welche Gruppe ihre Aufgaben zu spät erledigt hat, sollte man trotzdem loggen...
Warum das Ganze? Eigentlich sehe ich dies als Lernprojekt. Ich kann ein bisschen dies, ein bisschen das, aber möchte mich weiter einarbeiten und dazulernen. Dass dadurch alle putzpriviligierten Personen hoffentlich rechtzeitig ihre zugeteilten Aufgaben erledigen, ist natürlich auch gewünscht ^^
Ich definiere einfach mal die Anforderungen:
Haushaltsplan für 2 Gruppen. Gruppe 1 erledigt in ungeraden Wochen die Tasks der Tage 1,3,5,7 Gruppe zwei entsprechend 2,4,6; in geraden Wochen tauschen die Gruppen die Tasks.
Ob ich nun für jeden Raum eine eigene Tabelle festlegen, oder alles in eine schreiben soll, ist letztendlich egal; sobald alle Tasks einmal festgelegt sind, wird sich an dem Grundgerüst der Tabelle vermutlich wenig ändern. Ggf. könnte man unregelmäßigere Tasks (Gartenarbeit, Aussortieren von Schränken, whatever???) in eine eigene Tabelle auslagern.
Die Deadline muss innerhalb der Tabelle nicht unbedingt eine genaue Uhrzeit haben; das Script, welches die Tabelle letztendlich ausliest, kann das selbst vornehmen und ggf. Alarm schlagen (nette Version: per E-Mail; nicht so nette Version: Jabber, E-Mail, SMS, ggf. automatisierte Sprachmitteilung per Asterisk
), wenn die Tasks zu bestimmten Uhrzeiten nicht erledigt sind.Der Ansatz, wer welchen Task wann erledigt hat, ist gut. Allerdings hatte ich es mir so vorgestellt, dass irgendwo ein Tablett hängt, welches alle offenen und erledigten Tasks in einer Tabelle (PHP sollte reichen?) anzeigt. Sobald jemand seinen Task erledigt hat, kann sie oder er dort kurz klicken und der Task wird als erledigt markiert. Das Tablett soll zentral hängen und ohne spezifische Userzuordnung klarkommen; ob Person A oder B von Gruppe 1 oder C oder D von Gruppe 2 den entsprechenden Task nun erledigt haben, ist somit nicht nachvollziehbar.
_Wann_ jemand bzw. welche Gruppe ihre Aufgaben zu spät erledigt hat, sollte man trotzdem loggen...
Warum das Ganze? Eigentlich sehe ich dies als Lernprojekt. Ich kann ein bisschen dies, ein bisschen das, aber möchte mich weiter einarbeiten und dazulernen. Dass dadurch alle putzpriviligierten Personen hoffentlich rechtzeitig ihre zugeteilten Aufgaben erledigen, ist natürlich auch gewünscht ^^
Moin carl7n,
na, dann will ich dir den Spass am Ausprobieren und Verfeinern nicht nehmen - es heisst ja Entwicklung und nicht Standardlösungen kopieren.
Nur drei Anmerkungen:
Grüße
Biber
na, dann will ich dir den Spass am Ausprobieren und Verfeinern nicht nehmen - es heisst ja Entwicklung und nicht Standardlösungen kopieren.
Nur drei Anmerkungen:
- ich würde die "in der Zukunft liegenden Aufgaben" nach wie vor per INSERT-Statements anlegen für einen realistischen Zeitraum (=NICHT für 10 Jahre im Voraus). Auch wenn vermeintlich diese "Gesetzmäßigkeiten" mit geraden/ungeraden Wochen oder "jeden dritten Dienstag im Monat" in der Theorie irgendwie bestechend einleuchtend sind- hey, schau doch mal nach 2 Monaten, ob das so passt im wirklichen Leben
- wenn du jemand eine Mail, eine SMS, whatever senden willst, dann muss schon a) ein Task einer Person/einer Gruppe zugeordnet sein und b) diese Person/diese Gruppe auch ein paar Attribute haben (Name, Mail-Adresse, TelNr,..)
- jeweils eine eigene Tabelle für den Task "Klo-Putzen", "Kühlschrank abtauen", "Aschenbecher kärchern" etc. ist absurd. Das sind alles "Aufgaben" und haben keine signifikant unterschiedlichen Attribute.
Grüße
Biber
Ich bin natürlich trotz Lernbereichtschaft äußerst dankbar für praktische Tipps ;)
"in der Zukunft liegende Aufgaben": wir hatten einen derartigen Plan schon mal im Oldschoolformat (ausdrucken, abhaken)... Das hat eigentlich ganz gut funktioniert. Eigentlich ;) Bis dann eine Person aus der Routine kam, die nächste dann davon beeinflusst wurde etc. Dass bestimmte Dinge zeitlich aufeinander abgestimmt werden, halte ich schon für sinnvoll. Sagen wir mal, Person 1 muss jeden Tag X Staub saugen. Person 2 muss an demselben Tag alle Ablageflächen wischen. Um effizient zu arbeiten, sollte Person 2 zu einer halbwegs annehmbaren Zeit alles gewischt haben, damit Person 1 den dadurch entstandenen Dreck gleich mit weg saugt.
Grundsätzlich habe ich die Erfahrung gemacht, dass es am einfachsten abläuft, wenn solche Abläufe zeitlich aufeinander abgestimmt sind. Und das Erarbeiten sehe ich erstmal als reines Lernprojekt. Kann auch gut sein, dass ich das über ein paar Wochenenden zusammenschustere und sich im Endeffekt keine 48 Stunden daran gehalten wird :D
Da hast Du natürlich Recht mit der Personenzurodnung. Macht es Sinn, wenn ich das so löse:
Tabelle 1: ID, Name, Email, Jabber, ggf. Telefonnummer, Analyse
Tabelle 2: ID, Zimmer, Task, Wer, Deadline
Tabelle 3: ID (aus übereinstimmend mit Tabelle 2), Status, wannErledigt
Tabelle 2 wäre somit komplett statisch. Hier wird nur gelesen, was zu tun ist. In Tabelle 3 werden regelmäßig die neuen Werte geschrieben (bis auf ID). Tabelle 1 ist statisch, bis auf das Feld "Analyse" (hier könnte man einen Score errechnen, wie oft jemand Tasks nicht bzw. zu spät erledigt hat; ggf. kann man die Analyse zum Anfang auch weglassen und später implementieren)
.
Macht das Sinn? Also wie in diesem Fall die verschiedenen Werte auf einzelne Tabellen verteilt sind? Meine Grundidee war zuerst
Tabelle 1: ID, Name, Email, Jabber, ggf. Telefonnummer (, Analyse)
Tabelle 2: ID, Zimmer, Task, Wer, Deadline, Status, wannErledigt
Das "Wer" in Tabelle 2 würde ich dann nicht mit Namen belegen, sondern einfach a lá A,B,C,D. In Woche 1 bin ich A, in Woche 2 (wegen des Aufgabentausches) bin ich B usw.
Den Reminder schickt das Script raus. Dieses ordnet zu, wer wann "Wer" ist und sucht sich die entsprechenden Kontaktinformationen aus Tabelle 1.
"in der Zukunft liegende Aufgaben": wir hatten einen derartigen Plan schon mal im Oldschoolformat (ausdrucken, abhaken)... Das hat eigentlich ganz gut funktioniert. Eigentlich ;) Bis dann eine Person aus der Routine kam, die nächste dann davon beeinflusst wurde etc. Dass bestimmte Dinge zeitlich aufeinander abgestimmt werden, halte ich schon für sinnvoll. Sagen wir mal, Person 1 muss jeden Tag X Staub saugen. Person 2 muss an demselben Tag alle Ablageflächen wischen. Um effizient zu arbeiten, sollte Person 2 zu einer halbwegs annehmbaren Zeit alles gewischt haben, damit Person 1 den dadurch entstandenen Dreck gleich mit weg saugt.
Grundsätzlich habe ich die Erfahrung gemacht, dass es am einfachsten abläuft, wenn solche Abläufe zeitlich aufeinander abgestimmt sind. Und das Erarbeiten sehe ich erstmal als reines Lernprojekt. Kann auch gut sein, dass ich das über ein paar Wochenenden zusammenschustere und sich im Endeffekt keine 48 Stunden daran gehalten wird :D
Da hast Du natürlich Recht mit der Personenzurodnung. Macht es Sinn, wenn ich das so löse:
Tabelle 1: ID, Name, Email, Jabber, ggf. Telefonnummer, Analyse
Tabelle 2: ID, Zimmer, Task, Wer, Deadline
Tabelle 3: ID (aus übereinstimmend mit Tabelle 2), Status, wannErledigt
Tabelle 2 wäre somit komplett statisch. Hier wird nur gelesen, was zu tun ist. In Tabelle 3 werden regelmäßig die neuen Werte geschrieben (bis auf ID). Tabelle 1 ist statisch, bis auf das Feld "Analyse" (hier könnte man einen Score errechnen, wie oft jemand Tasks nicht bzw. zu spät erledigt hat; ggf. kann man die Analyse zum Anfang auch weglassen und später implementieren)
.
Macht das Sinn? Also wie in diesem Fall die verschiedenen Werte auf einzelne Tabellen verteilt sind? Meine Grundidee war zuerst
Tabelle 1: ID, Name, Email, Jabber, ggf. Telefonnummer (, Analyse)
Tabelle 2: ID, Zimmer, Task, Wer, Deadline, Status, wannErledigt
Das "Wer" in Tabelle 2 würde ich dann nicht mit Namen belegen, sondern einfach a lá A,B,C,D. In Woche 1 bin ich A, in Woche 2 (wegen des Aufgabentausches) bin ich B usw.
Den Reminder schickt das Script raus. Dieses ordnet zu, wer wann "Wer" ist und sucht sich die entsprechenden Kontaktinformationen aus Tabelle 1.
