Also anständig macht man das so:
In der Tabelle ist die Spalte vom Typ smalldatetime,
die Methoden geben DateTime zurück und kein string,
die Parameter setzt du (wie du es immer machen solltest) mit SqlParams und bastelst keinen string zusammen.
Hm... sicher, dass die mysql.h in ...\MySQL\MySQL Server 5.1\include liegt? Wenn du bei #include den ganzen Pfad angibst, versuch mal #include "\"C:/Programme/...\"" (k. A. ob das funktioniert, habs nicht getestet). Wenn du die mysql.h schon in den Dev-Cpp Ordner kopierst, dann bitte nach ...\include , nicht nach ...\include\c++ .
Tja, mit Linux wäre das nicht passiert. *scnr*
Ich hab wohl irgendwie ein Brett vorm Kopf
Hat vielleicht jemand ein Beispiel für mich, wie ich eine Tabelle mit Integritätsprüfung (Begrenzung des Eingabebereiches) unter mysql bewerkstelligen kann ?
Unix-Tom schrieb:
Da das Land aber auch in anderen Tabellen gebraucht wird schreibt man da wieder den Namen als VARCHAR rein?
Nein!!!
Man schreibt gem. Normalisierung die ID rein.
Keine Normalform sagt dass das nicht OK wäre. Vorausgesetzt man betrachtet den Ländernamen als Key (was nicht unüblich ist!).
Welchen Candidate-Key ich mir als Primary-Key aussuche ist doch immernoch meine Entscheidung.
Falls du anderer Meinung sein solltest, bitte gib mir einen Link wo das erklärt ist, denn ich kenne wirklich keinen Artikel der etwas anderes behauptet.
----
Es ist aber aus anderen Gründen keine gute Idee.
Der Ländername könnte sich ändern (Tippfehler oder warum auch immer). Natürlich können viele aktuelle DBMS' Foreign-Key Spalten automatisch anpassen. Allerdings sollte man als Key IMO immer nur unveränderliche Daten verwenden. Ein vollkommen bedeutungsfreier Integer ist da praktisch. Der Ländername wird dadurch zu einem Attribut, und darf frei geändert werden.
Performance. Strings vergleichen/sortieren/indizieren etc. ist *sehr* langsam. Viele machen den Fehler zu denken "naja, vergleicht er halt 32 Byte statt 4, ist ja nicht so schlimm". In Wirklichkeit ist ein String-Vergleich in bei den meisten DBMS' wesentlich aufwändiger. Es müssen aus den eigentlichen Strings erstmal Sortkeys erstellt werden, und das ist recht aufwändig. Die Sortkeys können dann verglichen werden (das ist der vergleichsweise billige Teil).
http://en.wikipedia.org/wiki/Collation
http://www.unicode.org/unicode/reports/tr10/
----
Also nochmal: die (sehr übliche) Vorgehensweise, "Integer-IDs" zu vielen Tabellen dazuzupacken, und diese dann zum Primary-Key zu erklären, hat zwar oft viele Vorteile, aber nichts mit Normalisierung zu tun.
Naja es gibt den SQL Server Profiler, mit dem kann man genau sowas machen. Sollte auf der Install-CD irgendwo mit dabei sein, bzw. ansonsten bekommt man die nötigen Files auch über MSDN subscriber downloads.
Mit dem SQL Server Profiler kannst du dich dann einfach auf den SQL Server hin connecten (du musst also am Server selbst nix installieren), und einen Trace starten. Da kannst du dir dann aussuchen was alles geloggt werden soll. Natürlich zieht das etwas Performance, aber wenns nicht sehr lange läuft sollte das egal sein.
sothis_ schrieb:
Badestrand schrieb:
Schau dir mal die Sprache SQL an
ich glaube er meinte eher das low-level transport protokoll von mssql über tcp/ip. und da würde es mich nicht wundern, wenn dies proprietär ist
Erstmal vielen Dank für die Antworten
Also.
Ich habe eine Funktion geschrieben, welche die Responses von einem FTP-Server parst und dann dementsprechend handelt.
Dazu habe ich mir die RFC959 zur Hand genommen
http://www.faqs.org/rfcs/rfc959.html
Und dort stehen ja die Server Responses und die FTP Commands für das FTP Protocol
Programm ist quasi:
Winsock starten
Sock starten
Connect zu IP
Read Buf
Dort ist dann ein "220" drinne + irgend ein Text.
Wie z.b.:
R] 220-FTP server ready.
R] 220 This is a private system - No anonymous login
Nun sendet das Programm den Befehl\String "USER Admin"
Wieder Read Buf
Dort ist dann ein "331" drinne, das schaut denn meist so aus:
[R] 331 User Admin OK. Password required
Programm sendet den Befehl "PASS secret"
Der Server antwortet denn 230, wie z.b. Passwort OK,eingeloogt
Nun ist man connected und kann eben weitere FTP Befehle senden...download,upload,ordner erstellen etc.pp
Meine Frage ist nun, wie schauen die Server Responses von einem MSSQL Server aus? Und was erwartet der MSSQL dann?
Gibt es dazu eine öffentliche RFC?
Ist es überhaupt möglich ein MSSQL-Client zu schreiben ohne irgendwelche API´s?.
Ich wollte eigentlich keinerlei API´s nutzen, sondern einfach Winsock.
hustbaer schrieb:
Nö.
MySQL unterstützt dynamic SQL anscheinend nicht wirklich. Zumindest hab' ich nixe zu dem Thema gefunden, ausser eben die prepared statements. Kenne mich mit MySQL auch nicht so toll aus. Nimm SQL Server Express
Hehe .. nimm einfach eine andere Datenbank ist einfach gesagt.
Unix-Tom schrieb:
Bei dir hört sich das an an als wäre es ein Feature welches die Welt nicht braucht und nur weil es dies bei MS gibt ist MSSQL böse.
Kann mich auch irren und habe dich falsch verstanden.
Da hast du mich gänzlich falsch verstanden. Ich meinte damit bloss, da der OP noch MSSQL 2000 verwendet, fällt es für ihn aus. Und für die meisten anderen Anwendungen auch, wenn man sich nicht frei eine neue DB aussuchen kann. So war das gemeint.
Dass es ein sehr nützliches Feature ist denke ich auch. Ich hätte MSSQL 2008 zwei Jahre früher brauchen können, dann würde ein File-Repository unserer Firma (mit ein paar TB) heute anders aussehen. Naja... vielleicht macht sich mal wer die mühe das zu portieren
Danke! Ich habe selber parallel etwas gegoogelt und bin auch auf odbc gekommen. Hier gibts die wohl auch bei IBM zum download:
http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg21255394#r4
Soo, nun hab ich die runtergeladen und soll das in ein mir genehmes Verzeichnis entpacken... Und dann konfigurieren und registrierenn.
Mal sehen, wies weitergeht....
Vielleicht gehört er auch zu den Programmierern die sogar hin und wieder mal Corner-Cases testen, und andere sollten sich ein Beispiel nehmen. Vielleicht ist er auch durch Zufall draufgekommen, und hatte dann so ein schlechtes Gewissen, dass er es fixen wollte.
Vielleicht ist aber auch ganz egal wieso er dahintergekommen ist, und nur wichtig, dass es ein Fehler ist, denn man definitiv nicht ignorieren sollte. Vielleicht bist du aber auch anderer Meinung, und schreibst gern Programme die nur meistens funktionieren. Vielleicht würde ich dich dann aber für ne Doofnuss halten.
Du könntest mal versuchen, zwei Anfragen zu starten und diese zu vereinigen:
SELECT * FROM table ORDER BY used DESC LIMIT 10
UNION
SELECT * FROM table ORDER BY name
Durch die Vereinigung und das Ausfiltern der Top10 aus dem zweiten Statement (UNION statt UNION ALL) könnten aber die Datensätze wieder durcheinandergewürfelt werden. Ein Trick könnte nun darin bestehen, zusätzliche Sortierspalten anzufügen und danach nocheinmal abschließend zu sortieren:
SELECT * FROM (
SELECT *,'1' as sort1,used as sort2 FROM table ORDER BY used DESC LIMIT 10
UNION
SELECT *,'2' as sort1,name as sort2 FROM table ORDER BY name
) v
ORDER BY sort1,sort2
Wieweit das mit MySQL geht weiß ich nicht.
@Mods: Bitte den Thread ins VCL / BCB Forum verschieben.
Topic:
Am besten gar nicht. Nimm Query-Objekte. TTable funktioniert nur mit Paradox und dBase reibungslos. Bei SQL-Server wird es früher oder später Probleme geben.
Hallo Unix-Tom,
was ich gesehen habe war Kettle (Java):
http://it-republik.de/jaxenter/artikel/Kettle-und-die-Entwicklung-eines-eigenen-Plug-ins-1302.html
MS SQL wollte ich nicht extra installieren.
Viele Grüße
Marek
Wenns dir nur um die Geschwindigkeit bei Abfragen geht, dann wird ein Index vermutlich reichen.
Ansonsten stimmt es schon, dass String-Vergleich viel viel Aufwändiger sind, als Integer-Vergleiche.
Und... wenn du einen Server willst, der mehrfache Strings innerhalb einer Page "wegoptimiert", dann solltest du dir den MSSQL 2008 angucken.
http://blogs.msdn.com/chadboyd/archive/2007/07/28/katmai-sql-2008-data-compression-including-backup-compression.aspx
SQL Server kann also gleiche und ähnliche Daten aus unterschiedlichen Zeilen innerhalb einer Page komprimieren.
Wenn ich den TOAST Artikel richtig verstehe, dann kann PostgreSQL nur einzelne Felder für sich komprimieren. D.h. in dem Fall, wenn ein Feld in vielen Zeilen den selben Wert hat, dann speichert PostgreSQL dennoch für jede Zeile die vollständigen Daten.
Guten Tag,
ich bin gerade dabei mit PHP5 und MySQL5 eine Suche über eine größere Datenbank zu programmieren.
Mein erster Ansatz war folgender:
SELECT
feld1,
feld2
FROM
tabelle
WHERE
feld1 LIKE "%suchbegriff%"
OR
feld3 LIKE "%suchbegriff%"
Das funktioniert zwar, jedoch sehr langsam (bei vielen Feldern und großen Datenmengen). Macht ja auch Sinn, dass es nicht schnell ist.
Um es zu beschleunigen, habe ich einen FULLTEXT-Index über alle zu durchsuchenden Spalten angelegt und folgendermaßen gesucht:
SELECT
feld1,
feld2
WHERE
MATCH(feld1,feld3) AGAINST("suchbegriff*" IN BOOLEAN MODE)
Das ist nun deutlich schneller, allerdings findet er nur Prefixe und keine eingeschlossenen Wörter. Also: "mar" findet "Marketing" aber nicht "Wochenmarkt".
Ich bin nun also auf der Suche nach einer schnellen Methode, um Wörter und Teilwörter in den Datensätzen zu finden.
Hat einer von euch damit bereits Erfahrungen gemacht und kann mir weiterhelfen? Vielleicht kann man auch die erste Methode in irgend einer Form beschleunigen?
Ich habe den ganzen heutigen Tag damit verbracht Google durchzuwühlen und das MySQL-Handbuch zu lesen, habe jedoch keine brauchbare Lösung gefunden.
Vielen Dank!
Daniel
zeitgleich bin ich noch auf eine andere Lösung gestossen, fragt sich was schöner ist
(isnull (c1 ,0) + isnull(c2,0) + isnull(c3,0))
/(CASE
WHEN isnull(c1,0) <> 0 and isnull(c2,0) <> 0 and isnull(c3,0) <> 0 THEN 3
WHEN ((c1,0) <> 0 or isnull(c2,0) <> 0) or isnull(c3,0) <> 0 THEN 2
WHEN isnull(c1,0) <> 0 or isnull(c2,0) <> 0 or isnull(c3,0) <> 0 THEN 1
WHEN isnull(c1,0) = 0 and isnull(c2,0) = 0 and isnull(c3,0) = 0 THEN 0
Else -1 End as 'Average'
