Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Linux/Unix in das Forum Datenbanken verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
Gerd Schneider schrieb:
Hallo,
ich habe eine DB mit einer Tabelle diw wie folgt aussieht, [...]
Wenn du alle funktionalen Abhängigkeiten quantifizieren kannst dann gibt es sogar einen Algorithmus nachdem du das alles normalisieren kannst. Der sollte sich in diesem Buch finden Datenbanksysteme | ISBN: 3486576909, die Seite weiß ich aber nicht mehr aus dem Kopf. Und wie Unix-Tom schon sagte Stufe 3 ist das Gängigste, mit Erfahrung und Gefühl bekommt man das sogar fast "automatisch" schon beim Entwurf hin, BCNF kann einem durchaus auch schon begegnen was höheres hab ich noch nicht gesehen ausserhalb des akademischen Rahmens.
"ID" ist sogar mit Sicherheit kein Primärschlüssel. Sonst würde er die Daten so gar nicht erst in die Tabelle kriegen, da das gleich eine Unique Constraint Verletzung geben würde. Ich schätze mal "ID" ist hier nur eine "Skizzierung" des Datenmodells. Als einzige Lösung würde mir für das Problem hier eine Funktion einfallen. Alles nach den gegebenen Kriterien selektieren und dann tauschen. Die Werte entsprechend in temporären Variablen speichern. Die ganze Aktion ist aber bereits erwähnt ziemlich fragwürdig.
sry, das war ein abschreibfehler. es wird nach schichten.felder gruppiert.
komischerweise habe ich das heute nochmal gestartet und es lief problemlos.
danke für deine Hilfe, ich weiss jetzt zwar nicht, wieso das nicht funktioniert hat, aber immerhin funktioniert es jetzt. Es waren auch nur Tabellen in dem Ausdruck, also kanns nicht an einer Abfrage gelegen haben.
Hallo zusammen!
Also mein Problem ist folgendes:
ODBC liefert mir auch bei NVARCHAR sowie NTEXT Feldern immer einen char String zurueck, scheint also den Text an meine Lokale Codepage anzupassen.
Das ist nicht unbedingt das gewuenschte Verhalten, sondern ich haette das ganze gern so wie es auch auf dem MS Sql Server gespeichert wird als UTF16 zurueck.
Das einzige was ich gefunden habe, was das vielleicht bewirken koennte waehre
SQLSetConnectAttr(m_hDBC, SQL_COPT_SS_TRANSLATE, (SQLPOINTER)SQL_XL_OFF, 0);
Aber weder mit eingeschaltetem Flag, noch ohne bekomme ich das Resultat meines Querys als wchar_t.
Die Daten hole ich mir ueber
SQLGetData(stmt,column,type,buffer,bufferLen,&od);
Gibt es eine Moeglichkeit das zu erreichen?
Ich faende es relativ komisch, mir die Daten aus einer Unicode Datenbank zu holen, sie nach MBCS zu wandeln und dann wieder nach UTF16, da die GUI damit arbeitet.
Danke schon mal.
cheers,
Sven
[Edit]
Ich benutze ODBC 3 im Visual Studio 2008 mit gesetztem Unicode Flag, uebergebe also auch die Querys als Unicode
[/Edit]
Danke erst ein mal für die Antwort. Daher schätze ich das Forum so, die Kompetenz und Erfahrung hinter den Leuten
Ich kann leider im Moment nicht soviele Informationen geben, da ich selber noch nicht richtig drinnen bin.
Das momentane System ist über 17 Jahre alt und läuft auf einem OS/2 rechner. Die Datenbank ist einfach ein hirachisches Filesystem. Jetzt soll es nach Windows portiert werden und auf einer relationalen Datenbank aufsetzen. Nun hat irgendwer schon vorarbeit geleistet und dieses hirachische Filesystem 1:1 auf ein Datenbankschema abgebildet, ich denke das sagt schon alles...
Daher: Schema nicht veränderbar, keine Integritätsbedingungen, über 100 Tabellen mit manchmal bis zu mehreren hundert Attributen
Sicher, es wäre ein interessantes Projekt, wenn da nicht die Basis wäre...
Na Du hast Lebewesen, Biotope und Mitarbeiter. Mitarbeiter sind zu den Biotopen 1:n zugeordnet also ist der Primärschlüssel des Mitarbeiters ein Fremdschüssel im Biotop. Die Lebewesen sind den Biotopen n:m zugeordnet also werden die beiden Primärschlüssel in einer Verknüpfungstabelle mit der Anzahl Brutpaare abgebildet.
PS: Welche Normalform war gewünscht? Wenn Du Ort, PLZ und Mitarbeiter-ID in einer Tabelle speicherst verletzt Du die dritte NF.
Ich verwende SQLite (allerdings noch 2.8) als lokalen Cache für Daten aus einem DB2-Server (Clients sind nur per 64 KBit-Standleitung, teilweise sogar nur per GPRS angebunden, darum tut jedes übertragene Byte weh). Ich habe keine Probleme mit mehreren gleichzeitigen Threads. Bei 2.8 war es allerdings noch so, dass während des Schreibens die komplette Datenbank gelockt wurde. Das wurde mit 3.x glaube ich geändert.
Allerdings muss jeder Thread seine eigene Instanz von SQLite öffnen. Ich hatte mal mit eigenem Locking rumexperimentiert (nur eine Instanz, per Mutex serialisiert). Die Datenbank blieb zwar stets konsistent, ich bekam aber viele Fehlermeldungen beim Versuch neue Datensätze hinzuzufügen. Offenbar hat SQLite einen eigenen Meachnismus um zu prüfen, dass jeder Thread seine eigene Instanz hat.
Unix-Tom schrieb:
INSERT INTO dates (datum) VALUES (NOW())
Ja. Ich habe jetzt gemerkt, dass ich gewohnheitshalber vor () immer einen Abstand gemacht habe, was MYSQL offensichtlich nicht so gerne hat.
Manni23 schrieb:
öh weis ja nicht ob ich dich jetzt falsch verstanden hab...
aber ist das nicht genau das was ich da stehn hab
Stimmt! Ich Blödmann habe die Fremdschlüssel unter Fahrten als PKW-ID und LKW-ID gelesen. Alzheimer.
Ansonsten kannst Du doch das zusammenbinden was Du brauchst. Was muss denn in LKW und PKW gesucht werden, was nicht bereits in Fahrzeug steht?
Habe mir heute SQLite 3.6.2 geladen und im CBuilder5 eine LIB erstellt. Nun wollte ich dies auch für VisualC++6 aber dort werde ich mit Fehlermeldungen überschwemmt.
SQLITE_EXPERIMENTAL int sqlite3_config(int, ...);
sqlite3.h(996) : error C2485: 'deprecated' nichterkanntes erweitertes Attribut
sqlite3.h(996) : error C2059: Syntaxfehler : '('
Weiss jemand wo mein Fehler liegt?
Mit 2. hast DU aber ein Problem wenn es sehr viele OR werden. Manche LIBS haben ein LIMIT.
Denke aber das Du etwas übers Design nachdenken solltest.
Warum gerade diese 100?
Kann man das nicht mit einem SELECT WHERE lösen?
Mittlerweile funktioniert das wunderbar mit SQLite - echt zu empfehlen !
Einfach anzuwenden und recht flexibel.
Die Performance kommt (gefühlt) nicht ganz an Btrieve 'ran, macht aber nichts.