
dr.dimitri
Mitglieder-
Gesamte Inhalte
1276 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Alle Inhalte von dr.dimitri
-
Dann verschenkt man grob geschätzt 50% von dem was ein moderner Datenbankserver leisten könnte. Das hört sich an, als ob Du versuchst etwas prozedural nachzuprogrammieren, obwohl es eigentlich in SQL gelöst werden könnte. Wenn die Daten über einen Cursor geliefert werden, dann hast Du ja schon mal zwei SQLs als Grundlage. Jetzt hängt es nur noch davon ab, was Du genau vergleichen möchtest und vor allem wie die Ergebnismenge aussehen soll. Dim
-
Du meinst, Du siehst nur Nachteile in einer nicht näher genannten Version von mysql. In wenn die Datei im Filesystem liegt, dann muss die nicht erst komplett von der Platte gelesen werden? Aha und wie machst Du das z.B. bei einem normalen Video im Filesystem? Dim
-
So etwas ist eigentlich schon seit Jahren nicht mehr zeitgemäß. Die Vorteile die dbwizard beschrieben hat sind auch gleichzeitig Dinge, die bei einer filesystembasierenden Lösung fehlen. Wenn es dir nur darum geht irgend etwas über den Browser anzuzeigen, dann wäre ein Streamingserver evtl. besser geeignet als eine reine DB. Allerdings bietet Oracle Multimedia (formally known as Oracle interMedia) auch spezielle Datentypen und Funktionen an um genau so etwas datenbankgestützt zu implementieren (ist allerdings nicht kostenlos). Zum Thema BLOBs in Datenbanken: Zahlen sind Binärdaten, Strings sind Binärdaten, Blobs sind Binärdaten. Was kann eine DB am besten? Daten verwalten - dafür wurde sie gemacht. Hat meine DB also Schierigkeiten, weil ich 10GB an Blobdaten darain speichern möchte, dann kann ich mir fast sicher sein, dass sie bei 10GB an "konventionellen" Daten auch so ihre liebe Not haben wird. Mein Tipp: Verwende PostgeSql oder wenn es auch was kosten darf die Oracle 11 Standard Edition One und speichere die Filme in der DB. Lerne wie deine DB und deine Programmiersprache mit Blobs umgeht und Du kannst dir viel Aufwand sparen, den die DB Entwickler schon für dich betrieben haben. Dim
-
Hi, da meine Freundin nach dem Tod ihrer Mutter auch Wohngeld beziehen muss mach dich mal auf folgedes gefasst: 1. Alle 3 Monate bei der Wohngeldstelle antanzen, Kontoauszüge vorlegen (den Verwendungszweck kanst Du schwärzen), dich blöd anmachen lassen usw. usw. 2. Offenlegung aller Einkommen (also auch die der Eltern, Geschenke von Verwanten etc.) 3. Es zählen auch Naturalien als Einkommen 4. Hat deine Freundin und Du den gleichen eingetragenen Wohnsitz wird das natürlich angerechnet 5. Such dir möglichst bald einen Job, denn Wohngeld zu beantragen ist alles andere als angenehm. 6. Für das theoretisch siehe Link des Vorposters Dim
-
Fachgespräch - Fragen zu Java und Datenbanken?
dr.dimitri antwortete auf Thema in IHK-Prüfung allgemein
Ich hatte in meiner Abschlussarbeit auch eine DB mit dabei (ist aber schon ein paar Jährchen her ) Die Fragen beschränkten sich darauf, was RI ist und wozu man das benutzt und ein, zwei weitere kleine Fragen (allerdings hatte ich den Eindruck, dass sich meine Prüfer nicht so im DB bereich auskannten). Was in dem Zusammenhang aber auch dran kam war die unvermeidliche Datenschutzfrage. Da solltest Du dich drauf vorbereiten. Falls du einen Prüfer dabei hast der sich mit der Materie auskennt, wird sicherlich (je nach Art der Anwendung) die Frage kommen wie du die Multiuserfähigkeit sichergestellt hast, welches Locking deine AW verwendet (optimistisch oder pesimistisch) und warum, wie deine AW skaliert und ob Du datenbankspezifische Speziallösungen eingebaut hast bzw. einbauen musstest. Interessant wäre auch zu wissen, was das Tool denn genau macht. Dim -
Nein, aber das wurde dir ja auch schon an anderer Stelle gesagt: Exceptionbahndlung im SQL Loader - Entwickler-Forum Dim
-
Ein Highscore über alle Datensätze oder soll nur der maximale wert eines Users verwendet werden? Soll der Highscore alle user beinhalten oder z.B. nur die 10 besten? Welche DB (Hersteller) verwendest Du? Dim
-
Wusste gar nicht, dass es soviele von uns hier gibt. Komm aus Simbach/Inn. Ich fahr jeden Tag mit dem Zug rauf und runter. 35K Einsiegsgehalt ist sicherlich ok. Bei der Größenordnung der Firma denk ich aber auch, dass es da als Einsteiger nicht viel zu Verhandeln gibt - war bei mir auch nicht anders. Dim
-
Hi, also für dich wäre Application Express optimal. Doku und Tutorials findest ja schon auf der obigen Seite. Des weiteren empfehle ich dir noch dieses Buch und die deutsche Apex Community Seite. Glaubt den Quatsch immer noch wer? Dim
-
Schon erstaunlich, auf welchem hohen Ross hier so mancher unterwegs ist. Dim
-
Ich würde mal mit 40Tsd Anno reingehen. Dann hast Verhandlungsspielraum und wenn es dann ~35 werden passts auch noch für den Anfang. So wie ich das verstanden habe, leistest Du ja die komplette Vorarbeit für die weitere Auftragsbearbeitung sowie die Nachbearbeitung. Das sollte, wenn es sauber erledigt wird, schon etwas wert sein. Dim
-
Für solche Anforderungen gibt es Volltextindizes. Damit findest Du bei einer Suche nach Meier z.B. auch einen Mayer oder Maier. Ich weiß nicht ob Access das bietet aber das ist eben dann eine der vielen Einschränkungen die man hinnehmen muss, wenn man damit arbeitet. Wenn es sich nicht nur um eine Übungsaufgabe sondern um ein echtes Projekt handelt, würde ich sowieso empfehlen von Access abstand zu nehmen und direkt auf eine richtige DB umzuschwenken. Beispiele wären hier z.B. PostgreSql oder die kostenlose Oracle XE Edition. Dim
-
Alle die Du ihm mitteilst: FIELDS TERMINATED BY 'was_auch_immer' OPTIONALLY ENCLOSED BY 'irgendwas' AND 'irgendwas_anderes' Dim
-
SELECT STATEMENT CHOOSE Was hast Du denn da für ne alte Version?
-
Bei einem LIKE 'xyz%' kann ein Index verwendet werden bei einem LIKE '%xyz' nicht (theoretisch kann er schon verwendet werden, nur müsste die DB den ganzen Index durchsuchen und in diesem fall ist ein Full Tablescan deutlich schneller. Dim
-
Ich glaub Du bist der heutige Gewinner. Der Thread ist über 2 Jahre alt.
-
Verbesserung der Performanz dieses Statements
dr.dimitri antwortete auf Fenixxus's Thema in Datenbanken
Sofern auf ID ein Index liegt, und ID wie der Name schon sagt eindeutig ist, sollte das auch bei Milliarden von Datensätzen eine Sache von ms sein(*). Für die maximale ID muss die DB einfach nur den letzten Eintrag im Index lesen (also auf dem Block ganz rechts), und anschließend mit diesem Wert nochmal auf den Index zugreifen, daraus die Zeile in der Tabelle ermitteln und diese zurückgeben. Ist die ID eindeutig, kannst Dir das LIMIT sparen. ORDER BY kannst auf jeden Fall weglassen, da alle ID Spalten ja den gleichen Wert haben. Dim (*) Hab das grade mal bei einer 220 Mio Zeilen Tabelle in Oracle probiert: 94ms beim ersten, 47ms beim zweiten Aufruf. -
Eine correlated Subquery wird meistens (aber nicht ausschließlich) in einem Update verwendet (man nennt das Konstrukt dann auch correlated Update), Du kannst sie aber auch in einem Select verwenden. Wichtig ist eben, dass eine Verknüpfung (korrelation) zur übergeordneten Abfrage vorhanden ist. Fehlt diese Verknüpfung, dann ist es eine "normale" Subquery. Dim
-
Die correlated Subquery besitzt eine Verbindung zur übergeordneten Query. Der Bereich den ich fett gemacht hab in meinem Beispiel. Du kannst natürlich auch eine Subquery ohne korrelation verwenden. Naja eine Unterabfrage (Select im Select) eben: select a.* from (select a,b from tabx) a oder select * from tabX where x=(select col from tabY where id=xy) Dim
-
Den Begriff correlated Subquery verwendet man eigentlich nur wenn es um einen Update geht: update tab1 x set (a,=(select c,d from tab2 y where [b]x.id=y.id[/b][/code] Damit sind die übergeordnete und untergeordnete Abfrage miteinander verbunden. Dim
-
Es ist ein Alias. Damit kannst du mittels a.spaltenname ganz gezieklt auf eine bestimmte Spalte zugreifen, wenn z.B. in deinem SQL dieser Spaltenname von mehreren Tabellen verwendet wird. Ich hätte auch Hugo schreiben können. Ja. Die Ergebnismenge wird behandelt wie eine normale Tabelle. Dim
-
Du meinst in eine neue Tabelle. Eine Relation ist nichts physikalisches. So: insert into ziel (spalteA,spalteB) select spalte1,spalte2 from (select spalte1,spalte2 from quelle order by spalteXY) a where rownum <=100; Damit lädst Du 100 Zeilen aus der Quelltabelle. Du kannst es auch ohne Subselect machen, allerdings sind die 100 Zeilen dann zufällig gewählt. Rownum ist eine sog. Pseudospalte, die dem Ergebnis dynamisch zugewiesen wird. Dim
-
Richtig. Bei einer Gruppierung werden Daten zusammengefasst (eingedampft). Zusammenfassen kann man aber immer nur, wenn alle relevanten Spalten gleich sind. Daher wird nach A und B gruppiert und nicht innerhalb von A nochmal nach B (wie sollte das auch aussehen). Im Umkehrschluss ist es auch vollkommen egal ob Du GROUP BY a,b oder GROUP BY b,a schreibst. Dim
-
Hast Dir schon mal Application Express angesehen? Als Plattform würde dann die 11g Standard Edition One in Frage kommen. Kostet momentan 3733 € pro CPU (maximal 2 Stück) bzw. 116 € wenn ihr eine named User Lizenz möchtet. Dazu kommen noch ca. 800€ Supportkosten/Jahr dazu (falls gewünscht). Hört sich auf den ersten Moment nach viel Geld an, das sollten einem die Daten aber auch wert sein. Gerade bei Blobs hat Oracle einiges zu bieten und bietet entsprechende Unterstützung auch in Apex an. Besonders wichtig ist auch Backup&Recovery. In den seltensten Fällen wird es reichen einfach mal die nächtliche Sicherung einzuspielen, weil die Daten das aktuellen Tages dann verloren sind. Unabhängig welche DB du verwendest schau dir vorher an, wie Backups gemacht werden, ob zu jedem beliebigen Zeitpunkt zurückrecovered werden kann etc. Zum Thema Apex kann ich dir dieses Buch empfehlen. Dim
-
Hi, das nennt sich correlated subquery: UPDATE tabelle a SET (spalte1,spalte2)=(select spalteA,spalteB FROM tabelle b WHERE [b]a.id=b.id[/b] --Hier werden die beiden Mengen eindeutig miteinander verknüpft AND ...) WHERE a.spalteXY=... --Hier evtl. noch die zu berücksichtigende Menge einschränken Dim