![]() |
Datenbank: firebird • Version: 2.1 • Zugriff über: ZEOS 6.6.6
Basic-Frage
Hallo Leute...
eine sehr einfache Frage: Ich möchte einen Datensatz kategorisieren ( über 40 dynamische AND/OR Kategorie-Möglichkeiten stehen zur Verfügung) Bis dato (oh Gott, ich trau es mir gar nicht zu sagen..)schreib ich in ein "1000 char" Feld einen String wie diesen: a1c5d2a2d4
Code:
Nun suche ich alle Privatpersonen aus Deutschland die einen BMW fahren
a1 = "Deutschland"
c5 = "Privatperson" d2 = "BMW" ect select X from Y where .. and feld containing "a1" and feld containing "c5" and feld containing "d2" ... ist natürlich a Wahnsinns Performancebremse .. Wie macht man das OPTIMAL? Vielen Dank |
AW: Basic-Frage
|
AW: Basic-Frage
Bei deinem Beispiel würde ich der Tabelle für jedes Attribut ein Feld spendieren:
LAND - VARCHAR(50) PRIVAT - SMALLINT (0 / 1 = Ja / Nein) KFZMARKE = VARCHAR(50) Dann kannst du einfach abfragen:
Code:
Die vorhandenen Daten musst du dann natürlich irgendwie konvertieren...
SELECT X FROM Y
WHERE LAND = 'Deutschland' AND PRIVAT = 1 AND KFZMARKE = 'BMW' |
AW: Basic-Frage
Ich würde eher für Länder, Automarken etc. jeweils eine eigene Tabelle anlegen und die Fremdschlüssel darauf dann in jeweils einem Feld speichern. Deshalb ja mein Link.
|
AW: Basic-Frage
Danke für die Hinweise ...
Zusatzfrage: .. gibts irgendwie eine Art "binäre Lösung" ?
Code:
Feld1 = Vorname
Feld2 = Nachname Feld3 = Strasse .. Feld20 = 00000000000000100000000001000000011110000000001 und dafür eine schnelle SQL Abfrage? Vielen Dank |
AW: Basic-Frage
Hy,
das Zauberwort heisst hier wohl Normalisierung:
Code:
SQL:
tbl_person
id name etc. tbl_merkmal id name tbl_person2merkmal id id_person idmerkmal
Code:
...so viele rote Kästen...
SELECT * FROM tbl_person
INNER JOIN tbl_person2merkmal ON tblperson.id = tbl_person2merkmal.id_person INNER JOIN tbl_merkmal ON tbl_person2merkmal.id_merkmal = tbl_merkmal.id WHERE tbl_merkmal.name = 'BMW' |
AW: Basic-Frage
As I said before :zwinker:
@erich.wanker: Was genau meinst Du mit "binärer Lösung"? Was soll im Feld stehen und wie soll das ausgewertet werden? |
AW: Basic-Frage
Kleines Beispiel:
Code:
SELECT FIRST 300 SKIP 0 *
FROM DETAIL_DB INNER JOIN KEY_DB ON KEY_DB.INR_OWN = DETAIL_DB.INR AND KEY_DB.INR_PARENT = 92321 AND KEY_DB.INR_MENU = 3 AND DETAIL_DB.ERLEDIGT = 0 AND DETAIL_DB.PERMISSION_FOR_VIEW CONTAINING'a' AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING'd1' AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING 'z9' AND DETAIL_DB.STATUS_INFORMATION NOT CONTAINING 'x1' AND DETAIL_DB.STATUS_INFORMATION CONTAINING 'a1' AND DETAIL_DB.STATUS_INFORMATION CONTAINING 'b1' ORDER BY DETAIL_DB.DATE2 ASCENDING, DETAIL_DB.OBJECT_NAME Das Feld DETAIL_DB.STATUS_INFORMATION ist das besagte "Stringkategorisierungsding" Cool wäre es wenn ich auf INNER JOIN verzichten könnte, weil ich im Vorfeld schon einige brauche. Meine binäre Vorstellung wäre:
Code:
und eine Abfrage wäre lt. meiner Phantasie:
Ein Feld hat Wert: 0000000000000000000000000100000100010000011111
Code:
x = egal was auf dieser Position steht
Select X from Y where Feld = "xxxxxxxxxxxx0xxxxx1xxxxx0xxxxxxxxxxxxx11"
and Feld NOT "xxxxxxxxxxxxxxxxxxxxxxxx1xxxxxxxxxxxxxxxxx" ich hoffe, ich hab mich halbwegs verständlich ausgedrückt Danke |
AW: Basic-Frage
Sollen das jetzt Zahlen sein oder Strings? Das Hauptproblem bleibt doch: Deine Daten sind nicht atomar, da stehen mehrere Werte in einem einzigen Feld. IMO bringt es wenig bis nichts, einen Designfehler durch "krumme Tricks" wie Binärvergleiche ausbügeln zu wollen. Und ob Du nun einen INNER JOIN hast oder 20, welche Rolle spielt das? Sollte Dir das zu unübersichtlich werden, erstelle Dir doch eine Sicht.
|
AW: Basic-Frage
Die schnellste und variabelste Lösung wäre m.E. die von Rapante:
![]() Eine Binär Lösung würde m.E. an der Einschränkung der Zahlentypen leiden, ok schnell, aber untypisch für SQL und in vielen SQL Dialekten wg der notewendigen Binär Operatoren auch nicht ohne weiteres umsetzbar. (Vermutung: Die Darstellung hier ist zwar textuell, soll aber binär umgesetzt werden) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:17 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz