Eine weitere Möglichkeit einen ODBC Treiber zu verwenden (also abgesehen davon direkt die ODBC Funktionen aufzurufen), wäre ADO zu verwenden.
Ob das ein echter Vorteil ist falls man sich nicht schon mit ADO auskennt kann ich allerdings nicht sagen.
happystudent schrieb:
Wie kommt man da am einfachsten ran?
PRAGMA table_info [tabName]
in der 6. Spalte steht 0, wenn es kein PrimaryKey ist. Ansonsten ein Wert größer 0. Der Wert gibt dann die Position der Spalte im PK an, wenn es sich
um einen zusammmen gesetzen PK handelt. Das ist aber nicht bei jeder sqlite-version so. In älteren Versionen hatten alle PK-Spalten den Wert 1.
Das Problem ist wohl doch tiefgreifender als befürchtet. Das Modul auto_explain hat gezeigt, dass der Query Planer eine falsche Strategie wählt und einen langsamen sequentiellen Scan benutzt, obwohl er einen Index Scan benutzen könnte. Der Query Planer ist wohl sehr empfindlich, was selbst kleinste Änderungen am Quellcode angeht. Ich habe die IF NOT EXISTS (...) in Einzelschritte zerlegt und jetzt wird auch der Index Scan benutzt (Änderungen von SELECT 1 zu SELECT MAX( 1 ) führen wieder zum benutzen des sequentiellen Scans und sind wieder langsam. Genauso wie SELECT ... LIMIT 1).
Die schnelle Triggerunktion seiht jetzt so aus:
CREATE OR REPLACE FUNCTION public.fn_trigger_test()
RETURNS trigger AS
$body$
DECLARE
result INTEGER;
BEGIN
SELECT 1 FROM custom_data WHERE key = old.key) INTO result;
IF result ISNULL THEN
DELETE FROM custom_data_lookup_keys WHERE key = old.key;
END IF;
RETURN NULL;
END;
$body$
LANGUAGE 'plpgsql'
VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100;
Hi Asc,
asc schrieb:
muemmel, der Vorgang hatte schon seit etwa 3 Monaten keine weiteren Antworten mehr...
Hab leider auch erst nach dem Antworten gemerkt, dass ich gerade an einer angefaulten Leiche Wiederbelebungsversuche gemacht habe.
Manchmal bildet lesen eben nicht nur, sondern erspart - rechtzeitig angewendet - auch Arbeit.
Gruß Mümmel
hustbaer schrieb:
Ich tippe sowas nicht, dafür gibt es Copy+Paste
und Suchmaschinen, die dir heutzutage auch ziemlich gute Ergebnisse bei Schreibfehlern ausgeben. War vor 15 Jahren noch anders.
deejey schrieb:
ach so, es geht um Normalisierung
Geht es doch bei Einsteigerfragen immer. Ich verstehe ehrlich gesagt auch beim besten Willen nicht, wie du darauf kommst, dass es um TEXT gehen könnte bzw. auf welche Frage das die Antwort sein hätte sollen.
habs
select
tasks.id as `Id`,
tasks.title as `ItemName`,
GROUP_CONCAT(task_tasklists.tasklist_id) as `Lists`
from
tasks,
task_tasklists
where
tasks.id=task_tasklists.task_id
group by
tasks.id
SELECT Adminrechte
FROM Test
WHERE Benutzername LIKE 'Programfi' AND PasswortHash LIKE 'md5-checksumOderÄhnlichesHauptsacheNichtDasPasswortAlsKlartext'
Wenn bei dem oben genannten Select kein Wert heraus kommt -> den Benutzer gibt es nicht
Wenn genau ein Wert raus kommt -> dann solltest du ja als Ergebnis des Selects direkt den Wert haben, ob der Benutzer AdminRechte hat oder nicht
Wenn mehr als ein Datensatz zurück kommt -> dann solltest du evtl. noch UNIQUE constraints auf die Spalten Benutzername setzen, so dass es tatsächlich nur einen Benutzer mit diesem Namen gibt.
Die Spaltennamen "Benutzername", "PasswortHash" sind natürlich nur geraten ... du hast uns dein restliches DB-Schema ja nicht verraten
Nein ... ist nicht krass. Das ist normal so!
Genau dafür gibt es ja die Foreign Keys. Die sorgen dafür, dass deine Daten in der DB weiter Sinn ergeben. Sonst hättest du da auf einmal ein Buch in deiner Bücherliste mit einem Verweis auf einen Autor, den du nicht mehr in der DB hast.
Da gibt es dann mehrere Möglichkeiten damit umzugehen.
a) Löschen des Autors verbieten, solange irgendwelche Bücher mit diesem Autor "verknüpft" sind
b) auch alle Bücher dieses Autors löschen ... Stichwort Cascade Delete
c) DummyAutor Eintrag machen
d) Foreign Key entfernen ... (sollte man wohl nicht machen ... wäre aber eine Möglichkeite mit diesem Problem um zu gehen)
e) ... keine Ahnung was man sich hier noch alles ausdenken könnte ... ich denke a) und b) dürften die gängigen Varianten sein.
Test erfolgreich! Da die Datenmenge recht groß ist mussten allerdings noch einige MySQL-Parameter in der ini umgestellt werden, aber jetzt läuft es! Mit den prepared statements! Sehr guter Tip! Vielen Dank!
Also bei InnoDB Transactions kannst du dir sicher sein, dass die Transaction die ACID Kriterien erfüllt, und musst dir darüber eigenltich gar keine Gedanken machen. Du kannst davon ausgehen, dass alle Transactionen nacheinander passieren.
in Postgresql kann man die Größe der Tabellen auswerten. Wenn man dann weiß, auf welcher Platte die Tabelspaces liegen, dann weiß man ja auch, wie gros die ist und kann entsprechend reagieren.
Anderer Lösungsansatz - Tablespaces in eine extra partition packen und dann abfragen, wie voll die schon ist. Unter linux per df -h oder so unter Windows - müsste man suchen. Das täglich und wenn limit unterschritten irgendwo einen
Schalter setzen (z. B irgend eine kleine Datei irgendwo auf einem Plattenbereich, wo Datenbankserver und Archivierung beide Zugriff haben. Dann kann die Archivierung nachschauen und wenn Datei da, entsprechend reagieren.
Bengo schrieb:
Und nicht jedes Wort, dass irgenteine besondere bedeutung hat, muss auch ein Schlüsselwort sein. Schlüsselwörter sind nur diejenigen nach denen der parser sucht und nach denen er den query auswertet. Datentypen gehöhren da meist eher nicht zu.
Ja, wie gesagt, halt eine Liste die alle "besonderen" Wörter enthält. Ich hab das jetzt einfach mal "Schlüsselwörter" genannt weil mir nichts besseres eingefallen ist, aber ich suche halt einfach eine Liste mit allen "besonderen" Wörtern, egal ob diese jetzt "Schlüsselwörter" im engeren Sinn sind oder nicht.
Das ist soweit ich weiss gar nicht möglich, da MySQL die Daten die dazu nötig wären nicht erfasst.
Wenn es nur um transaktionale Tabellen geht (z.B. InnoDB), dann könnte es möglich sein die gewünschten Informationen aus dem Transaction-Logfile zu ermitteln.
Fertiges Tool dafür kenne ich aber keines. Kann sein dass du das Logfile dazu selbst parsen müsstest. Und das ginge dann wohl nur wenn der Server nicht gerade darauf zugreift. Also nicht "live".
Und für MyISAM Tables wird es wohl gar nicht gehen.
Du könntest aber mal schauen ob MySQL "profiling" unterstützt. Normalerweise sollte so ein Profiler die entsprechenden Zahlen ausspucken können. Dummerweise verschlechtert ein Profiler aber auch die Performance, d.h. man will ihn normalerweise nicht immer mitlaufen haben.
Der Code ist im Prinzip nicht Aussagekräftig, aber ich stelle ihn mal rein.
CBookTab tab;
//Öffnen und alles funktioniert gekapselt in try{}catch{}
tab.AddNew();
...
//Hier werden alle Werte gefüllt und sie stimmen auch bis zum:
tab.Update();
tab.Close();
//Hier eine Kontrolle in der Datenbank, die Spalte mit
//der langen Zeichenkette ist hinüber. Der Satz lässt sich nicht vernünftig lesen
Ich behaupte nicht, dass die Datenbank das Problem ist, ich denke auch nicht, dass die CBookTab das Problem ist, es wiurde von CRecordset abgeleitet. Ich habe gedacht es liegt am ODBC Treiber.
VG
Ranger
