Datenbank

Artchi

Ich hab gestern abend SAP DB auf mein Win2000pro installiert, war ganz easy. Erste Datenbank angelegt, Selects, Creates usw. per WebTools von SAP durchgeführt. Kann man nicht meckern. Auch ODBC usw. gleich alles im System eingetragen.

virtuell Realisticer

SUBSELECTS kommen in die MYSQL-DB rein. Fraglich warum man die brauchen sollte!

Jo und falls ich mich nicht irre, gibt es laut Standard gar keine Subselects,
oder liege ich da falsch? Wenn nich, verstehe ich nicht, dass solche Dinge, die
nicht im Standard sind immer als contra-Argument genommen werden.

Sollte ich falsch liegen, beuge ich mich der Wahrheit, aber ich meine Subselects
gehoeren nicht zum SQL Standard.

mfg
v R

TheBigW

Danke euch allen,

Dann werde ich wohl erstmal ein bisschen mit ODBC rumspielen und die finale Entscheidung noch ein bisschen vertagen - Bis ODBC für mich ein bisschen mehr als nur ein Wort ist .

Spacelord

Relationale DB und OOP passt einfach nicht,egal für welche du dich entscheidest.
Da entwirfst du die tollsten Klassen um die Attribute nachher wieder auf 150 normalisierte Tabellen zu verteilen .
Das dauert und kostet .

MfG Spacelord

Unix-Tom

Und zusätzlich bemerkt. Wenn du Performance willst lass die finger von ODBC

Artchi

hihi, aber jeder Kluge Geschäftsmann lässt sich Performance später extra bezahlen! Erst alles mit ODBC ansprechen, wenns später knapp mit Performance wird und der Kunde nörgelt, dann sagen "Wir können da ne Lösung ausarbeiten." und dann stellt man alles auf DB-API um (natürlich vorher an nen Wrapper denken, sonst macht es mehr Arbeit als wieder Kohle reinfliesst). Find ich nur legetim, da der Kunde zu Anfang eh immer nur den minimalsten Preis zahlen will und auch alles immer am liebsten gestern fertig haben will.

[ Dieser Beitrag wurde am 12.04.2003 um 13:53 Uhr von Artchi editiert. ]

Spacelord

HiHi,du kennst den Geschäftsführer der Firma wo ich (noch) arbeite???
Der will sich jetzt auch nen SAP für Arme anschaffen.Nen Arbeitskollegen von mir der Adminmässig wirklich was auf den Kasten hat,hat er letztens gesagt dass er zu doof ist (weil er nicht studiert hat) um den Job zu machen.Hat sich aber vorher von dem "Doofen" das komplette Netzwerk auf Vordermann bringen lassen. Nur als der Kollege dann ne angemessene Bezahlung haben wollte war er auf einmal zu doof dazu (wir arbeiten da beide regulär als Werkzeugmacher).
Naja,seit dem haben wir viel zu lachen!Die Inkompetenz der Studierten(nichts gegen Studierte,ich studiere selber nebenbei Informatik) ist wirklich allererster Güte.Letztens haben zwei Schlaue 1Woche(!!) gebraucht um im Netzwerk ne Datei von einem Rechner auf den anderen zu kopieren!!Und dann haben die sich,von der Firma die unseren Server wartet,nen Techniker kommen lassen um nen Rechner ins Internet zu bringen.Der gute Mann hat knapp 2 Stunden gebraucht die IP des Proxyservers im IE einzugeben .Das war ein teurer Spass aber,aus der Sicht vom Boss,immer noch besser als dem Kollegen von mir 1000 Euro mehr zu zahlen! Naja auf jeden Fall arbeitet das Armen-SAP mit jeder(!) DB zusammen,kann also auch nur irgend ne Standardschnittstelle sein die von der Performance her auch nix dolles sein kann.Mal abgesehen davon dass die Schlauen seit 4 Jahren am überlegen sind welche Daten die denn überhaupt verwalten wollen,glaubt der Alte allen Ernstes dass das ganze System nach 3 Monaten reibungslos läuft und dass er dafür auch keinerlei Administratoren braucht.Das ganze Softwarepaket soll so um 500000 Euro kosten und es ist echt keine Sau da(zumindest niemand der gefragt wird,weil der Mob ja doof ist)der auch nur annähernd beurteilen kann ob dass überhaupt was taugt!?
Wo Firma X mitbekommen hat dass der Kollege von mir nicht mehr für die EDV zuständig ist haben die erstmal die Korken knallen lassen!!
Wirklich cool,so nen Kunden kann man jedem EDV Unternehmen nur wünschen ;).

MfG Spacelord

gomberl

hi all

@Unix Tom:

Fraglich warum man die brauchen sollte!

also ich moechte mal sehen wie du komplexe auswertungen ohne sub selects zusammenstellst
ich hab bei meinem letzten projekt mich entschieden MySQL zu benutzen und diesen fehler werde ich nie wieder machen
dabei ist unsere datenbank (design von mir entwickelt) gar nicht so komplex - ich habe gerade einmal 100 tabellen und ein paar tausend datensaetze - was aber rapid ansteigend ist und wenn ich dann eine auswertung machen will dann schauts bloed aus mit der funktionalitaet von MySQL - jedesmal die ganzen sub selects vorher ausfuehren und dann nen String zusammenstellen um das ganze dann in einem simplen select laufen zu lassen - das ist es einfach nicht wert
ganz zu schweigen von dem kommunikationsaufwand - hin und herschicken von resultsets --- sowas gehoert sich nicht
zu dem transaktionsmechanismus sag ich jetzt nichts
ich hab mir das nur einmal angeschaut und so ganz sicher kommt mir das nicht vor
muss mich mal einarbeiten und schauen wie das im hintergrund funktioniert
aber transaktionen sind ja auf jedem rdbms ein graus - man denke nur an die verschiedenen implementierungen der isolation levels

@virtuell Realisticer:

Jo und falls ich mich nicht irre, gibt es laut Standard gar keine Subselects,
oder liege ich da falsch? Wenn nich, verstehe ich nicht, dass solche Dinge, die
nicht im Standard sind immer als contra-Argument genommen werden.

ich glaube da hast du was nicht wirklich mitbekommen
im SQL-1 standard (ueberarbeitung 89) gibt es keine sub selects
da gibt es nur:
Create Table,Create View, Grant, Revoke, Select, Update, Insert, Delete
allerdings ist dieser standard schon etwas veraltet
sub selects sind standard ab SQL-2 (SQL-92)
dieser standard stellt heutzutage das dar was jedes datenbank system koennen sollte (ist auch schon 11 jahre alt) und dort sind folgende dinge inbegriffen:
(je nach Conformance Level - Intermediate sollte pflicht fuer ein DB System sein)
E-SQL, Dynamic SQL,SQL 92 Join (explicit Join),Column Constraints,Sub Selects
und noch ein paar andere kleinigkeiten
wenn du dann den SQL-3 Standard hernimmst (99) dann bekommst du die ganze palette von trigger, stored procedures und so weiter
aber der ist nicht so wichtig (auch wenn mein liebster)

@TheBigW:
ich hab auch schon ueber das SAP DBMS gelesen - schaut ganz gut aus
PostGRE ist auch nicht so schlecht - skalliert besser als MySQL
ansonsten ist der MS SQL Server keine schlechte entscheidung - kommerziell gesehen
mach nicht meinen fehler - entscheide dich fuer das DB System nachdem du eine genaue spezifikation dafuer geschrieben hast
es gibt soviele systeme in der zwischenzeit - alle mit staerken und schwaechen

mysql solltest du nicht nehmen -- alleine schon wegen der fehlenden referentiellen integritaet - da stellen sich bei mir alle nackenhaare auf

wuensch euch noch was

gomberl

Unix-Tom

gomberl:

Du hast nicht den Fehler gemacht MYSQL zu verwenden sondern den SQL-Syntax auszunutzen.

Schon mal was von JOIN gehört.
Sind in der Mehrzahl der Fälle sogar effizienter als SUBSELECT.
Also bitte hier keine Falschmeldungen verbreiten.

@all: Jeder sollte die DB verwenden, die er für richtig,seinem Zweck geeignet und seiner Geldbörse angepasst hält.

[ Dieser Beitrag wurde am 13.04.2003 um 13:16 Uhr von Unix-Tom editiert. ]

gomberl

*grml* - browser abgestuerzt - jetzt muss ich alles nochmal schreiben

also:

@all: bei der bemerkung am schluss schliese ich mich unix tom auf jeden fall an - nur bin ich der meinung das MySQL nicht fuer grosse projekte gemacht ist - ich glaub das wollten die entwickler auch gar nicht - nur jetzt ist ein extremer hype darumherum

ich moechte jedem ans herz legen zuerst eine db spezifikation zu schreiben
was gebraucht wird und was nicht

ich dachte mir auch das wird kein so grosses problem mit der eingeschraenkten funktionalitaet - es geht auch so ganz gut
es ist nur extrem nervig wenn man nicht alles machen kann was der SQL standard unterstuetzt
bin jetzt ein fan von postgre sql - bin aber erst beim austesten was es wirklich kann

@unix tom:

falschmeldungen wuerd ich mir nicht erlauben - hab ein reines gewissen

Sind in der Mehrzahl der Fälle sogar effizienter als SUBSELECT

das mit den joins krieg ich nicht ganz mit:
wie machst du zB einen allquantor mit joins??? - hab mir das nicht ueberlegt aber ich denk mir so einfach wird das nicht sein - und ich meine natuerlich in einem einzelnen statement

gibts darueber was zu lesen - bin immer interessiert an neuen dingen ueber datenbanken - nachdem das ja mein spezialgebiet ist

zwischen einem join und einem sub select besteht bei mir ein grundsaetzlicher unterschied:
bei joins (gut zu sehen in 89er schreibweise) werden tabellen mit einem kreuzprodukt verbunden - zB joind 3 tabellen je 5 datensaetze
5 * 5 = 25 * 5 = 125 -- ganz schoen heftig - mal schauen auf ein beispiel aus der praxis: 1200 order * durchscnittlich 4 produkte pro order * 3 produktattribute:
1200 * 4 = 4800 * 3 = 14400 saetze
dannach wird der joint constraint ausgefuehrt und nur die benoetigten datensaetze zurueckgeliefert
mir ist schon klar das da viel optimiert wird (in jeder datenbank) - aber das ist mal das grundsatzprinzip
und was das mit einem sub select zu tun hat weiss ich nicht ein sub select ist quasi eine abfrage auf die datenbank die eine tabelle zurueckliefert (was ja jedes Select statement tut - auch wenn die tabelle leer ist) und dementsprechend auch den regeln eines selects unterliegt - das heisst verglichen wird nach der ausfuehrung des kompletten sub selects - das heisst nur mit dem resultset des sub selects

der EXIST operator zB hat in MySQL gar keine funktionalitaet - falls er existiert - das weiss ich gar nicht !

@All again: im grossen und ganzen ist zu sagen - die meisten datenbanken haben ihren zweck und sinn in ihrem speziallgebiet und generalisten ala Oracle oder MS SQL Server kosten dementsprechend

Unix-Tom

SUBSELECT
select * from score where event_id IN (select event_id from event where type = 'T');

UMFORMULIERT
select scrote.* from score, event where score.event_id = event.event_id AND event.type = 'T'

SUBSELECT
select * from student where student_id NOT IN (select event_id from absence);

UMFORMULIERT

select student.* from student LEFT JOIN absence On student.student_id = absence.student_id where absence.student_id IS NULL

Ich bin mir sicher das die UMFORMULIERTEN schneller (effectiver) ist.

gomberl

SUBSELECT
select * from score where event_id IN (select event_id from event where type = 'T');

UMFORMULIERT
select scrote.* from score, event where score.event_id = event.event_id AND event.type = 'T'

SUBSELECT
select * from student where student_id NOT IN (select event_id from absence);

UMFORMULIERT
select student.* from student LEFT JOIN absence On student.student_id = absence.student_id where absence.student_id IS NULL

ich weiss schon was du mit dem umformulieren meinst

aber zB Allquantor (doppeltes NOT EXISTS) ist etwas kompliziert zu loesen

um auf die basisfrage joins vs Subselects zurueckzukommen
hab mir das etwas ueberlegt und mit meinen unterlagen verglichen

die performance eines SubSelects haengt ganz vom Datenbanksystem ab.
normalerweise wuerde ein SubSelect ja fuer jede zeile ausgefuehrt (in der WHERE CONDITION) allerdings haben moderne datenbanken die moeglichkeiten zu analysieren ob sie das subselect im speicher halten koennen oder es jedesmal ausfuehren muessen (haengt davon ab ob man im sub select irgendetwas vom auesseren select nutzt oder nicht)

es gibt nun mehrere faelle:

SUB SELECT auf einem simplen dbs
wird immer ausgefuehrt - dadurch performance schwaecher als ein JOIN
SUB SELECT auf einem optimierten dbs - ohne referenz auf aeusseres select
wird nur einmal ausgefuehrt und dann im speicher gehalten - performance besser als ein JOIN der ja ein kreuzprodukt aller zeilen zuerst macht -- wobei wieder zu beachten ist das auf unterschiedlichen gut optimierten dbs die JOINS auch wieder schneller laufen - ich glaub das thema wird was fuer meine naechste ausarbeitung - danke fuer die anregung
SUB SELECT auf einem optimierten dbs - referenz zu aeusserem select
das sub select muss jedes mal ausgefuehrt werden
JOIN performt besser als SUB SELECT

ZUSATZ punkt 2:
fast vergessen
je weniger zeilen die tabellen enthalten desto mehr overhead hat ein sub select alleine durch die ausfuehrung einer eigenen query
dementsprechend performt es dann auch schlechter als ein JOIN

ZUSAMMENFASSUNG:
nach reiflicher ueberlegung muss ich mich UNIX TOM anschliessen (*verdammt*)
und sagen das JOINS im grossen und ganzen besser performen als Sub selects - auch wenn es in ausnahmefaellen in gut optimierten dbs umgekehrt ist
hat mir viel spass gemacht das auszudiskutieren
bin trotzdem der meinung das man SUB SELECTS sehr gut gebrauche kann

wir haben hier naemlich eines vergessen
SUB SELECTS als FROM-Tabelle --> kombination aus JOIN und SUB SELECT - wird nur einmal ausgefuehrt - dementsprechend auch gute performance - andererseits keine referenzen moeglich - grosse einschraenkung
und
SUB SELECTS IN DER PROJEKTION - sollten nur einmal ausgefuehrt werden
nur SUB Selects moeglich die 1 zeile und 1 spalte zurueckliefern

im endeffekt bleibt gesagt: SQL wirklich performant zu nutzen ist schwerer als gedacht - die diskussion hat mir wieder viel zum nachdenken gegeben

cu

gomberl