Mailinglisten-Archive |
On 08-Mar-2001 Julian Daniel Jimenez Krause wrote: > hallo, > > hier die ergebnisse meiner studie rund um das durchführen eines CREATE TABLE > von einem php-script aus, und als kunde con PURETEC: > > 1- *NUR* und genau nur statements der form CREATE TABLE tblname (rows +index > definition) werden geschluckt > > 2- ohne die (rows+index definition) wird nicht akzeptiert (entgegen der > CREATE-syntaxbeschreibung aus allen manuals) Zugegeben, die Syntax-Beschreibung aus dem MySQL-Manual von TCX ist nicht ganz eindeutig (problem ist wohl das es sie hier um zwei Sachen handelt, die zwar beide Optional sind, aber eben eine da sein muss (select, oder column definitions), aber: welchen Sinn soll ein Statement der Form "CREATE TABLE TEST;" haben? Eine Tabelle muss nun mal n Spalten (n>=1) haben, sonst ist es sinnlos, sagt dir MySQL ja auch (ERROR 1113: A table must have at least 1 column). Solltest vielleicht mal Fehlermeldungen ausgeben lassen (Frag mich nicht, wie es unter PHP geht, nehm ich nicht her), und nicht einfach nur checken obs geht oder nicht. ** hi, ich habe beim suchen nach beispielen mehrmals eine blanke CREATE TABLE tblname anweisung gesehen, ohne column-defitinion oder select-teil. in allen fällen würden die so erstellten tabellen später mit INSERT INTO tblname SELECT ... ausgefüllt. daher dachte ich, CREATE TABLE sei bei mySQL etwa äquivalent zu einem 'new CLASS_TABLE'..., d.h., just initialisieren eines objects... > 3- statements der form (laut manual und laut hunderten von beispielen im web > ganz ok) CREATE TABLE tblname SELECT ... FROM tbl ergeben einen fehler, d.h. > werden zumindest von der mysql-version von PURETEC *nicht* erlaubt!!!!!! > > 4- der flag 'TEMPORARY' (man siehe im manual) wird ebenfalls nicht > unterstützt und führt genauso zum fehler > > 5- TYPE=HEAP wird m.e. ignoriert Schon mal gecheckt welche Versionen Puretec einsetzt? Temporary Tables sind AFAIK erst seit 3.23.0 drin, die anderen Sachen gibts sicherlich auch nicht seit Anbeginn. Andererseits kann man natürlich mit HEAP-Tabellen den Speicher sehr schnell vollmachen, kann also auch eine Sicherheitseinstellung des Servers sein. ** in nachhinein ist mir klar geworden, dass PURETEC *unmöglich* ram-intensive konstrukte wie temporary oder heap tables zulassen kann, egal welche version die haben... hätte ich früher drauf kommen sollen... meine schuld. was aber ebenfalls nicht funktioniert und mich nervt (u.a. weil in keinem manual angaben über gültigkeit ab einer bestimmten version) sind: (a) CREATE TABLE tblname SELECT .... (b) der flag IF NOT EXISTS aber naja, damit kann man (muss man) leben... > die konsequenzen, die ich daraus schließe: > > - der lösungsweg, welcher ich anstreben wollte, ist auf mysql/PURETEC > *nicht* machbar, da ich dafür temporäre dateien erstellen müßte > > - die hilfs-metatabellen für die komplexere db-query, die ich bei jeder > session mittels temp-tables onthefly erstellen wollte, werde ich etwa > täglich "per hand" (php-script) erstellen müsen, mit dem gravierenden > nachteil, dass diese hilfs-metatabellen ggbf. *nicht* den aktuellsten stand > der datenbank darstellen (die datenbank kann und wird via web aktualisiert). Schon mal über ne andere Tabellenstruktur/Datenmodell nachgedacht? Irgendwie seh ich den Sinn nicht, wenn ich viele Selects in identisch aufgebauten Tabellen machen muss. Michael ** die identischen tabellen (haben alle die struktur id_tbl, id_item, id_kateg, value, remarks -- wobei id_tbl der unike key jeder tabelle; id_item der schlüssel zum organismus (es gibt ne organismentabelle); id_kateg der key zur eigenschaftskategorie gemäß der kategorientabelle), d.h. es wird eine n-m beziehung zwischen organismen und kategorien gebildet. die kategorien beschreiben unterschiedliche, disjunkte eigenschaften und werden hier deshalb gruppiert in verschiedenen tabellen -- etwa bei pflanzen: resistenzen gegen krankheiten bzw. verhalten in stresssituationen bzw. morphologische merkmale... klar kann ich sie alle in einer tabelle zusammenpacken (die kategorien-tabellen dann mit der extra spalte 'eigenschaft' die besagt zu welcher eigenschaft jeder kategorie angehört, spricht z.b. "krankheit" bzw "stress" bzw "morpho". da aber der auftraggeber für jede eigenschaftsgruppe eine extra eingabeform haben will, schien mir die lösung mit der aufteilung in mehreren tabellen sinnvoll, um mir u.a. die lästige arbeit mit filtern zu ersparen. aber auch wenn ich das so täte, bei der gestrigen aktion gings mir um eine sache, bei der ich auch wenn ich die eigenschaften alle zu einer tabelle zusammenfügen würde dasgleiche problem gehabt hätte. nämlich, der user sucht nach z.b. resistenz_gegen_krankheit_A = sehr gut & resistenz_gegen_dürre >= mittel & keimfähigkeit >= hoch; und will die ergebnisse geordnet haben nach einer additiven treffrelevanz der subqueries. das kostrukt, was ich gestern da vorstellte (mehrere schritte bis zur erstellung einer temp. flachen tabellen mit spalten für die treffrelevanz für jede subquery), tut das in FoxPro in millisekunden und ermöglicht mir die darstellung ganz nach den wünschen des kunden. eine lösung, wonach anstatt eine n-m beziehung zwischen organismen und kategorien direkt eine flache struktur mit sovielen spalten wie kategorien, ist (a) datenbankteschnich verheerend und (b) verbaut mir die möglichkeit schnell und problemlos eine kategorie zu löschen/ändern/hinuzufügen, ohne die forms berühren zu müssen. eine solche flachen tabelle würde aber die "subquery-additive treffrelevanz-suche" viel leichter machen. tja, datenmodelle sind immer irgendwo ein kompromiss.... danke für deine kooperation! gruß julián daniel --- *** Weitere Infos zur Mailingliste und MySQL unter http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive