nicht angemeldet
Prüfungsfragen -> Lazarus, Hierarchien
Hallo Forum,
ich habe demnächst Prüfungen und werde leider im Internet nicht so wirklich fündig.
Wir nutzen in der Schule Lazaraus mit der Bibliothek ZEOS und ich frage mich was nun folgende Begriffe genau bedeuten
1. Table-Lock, Record-Lock und Exclusive-Lock.
Table-Lock wäre mir klar, da wird zum Beispiel bei "Auto Commit" die ganze Tabelle gesperrt, anstatt nur der Datendatz, an dem ich editiere.
Was jedoch wäre Record und Exclusive?
2. Sagt jemand Catter X etwas?
3. Hab in den Wikis auch einiges über Hierarchien durchgelesen (Monohierarchie, Polyhierarchie, Nomenklatur, Facettenklassifikation)
Kann aber so grob die Vorteile und Schwächen von Monohierarchie und Facetten nicht so erklären.
Bei Monohierarchie hat jede Klasse nur eine Oberklasse, es gibt keine Querverbindungen, das heißt, dass manchmal etwas ähnlich, wenn es in zwei Bereiche hereinpasst, dass es zweimal aufgeführt werden muss. Das wäre dann wohl ein Nachteil.
Oder was meint man mit "keine semantische Relation"
4. Über multi-axiale Struktur wurde ich auch nicht fündig. Weiß zwar gerade nicht wohin das genau passt, aber es war wohl ein Nach- oder Vorteil irgendwo.
Würde mich freuen, wenn mir jemand Tipps geben könnte
Grüße
Michi
-
Hallo,
ich habe demnächst Prüfungen und werde leider im Internet nicht so wirklich fündig.
es wundert mich, dass Du für eine Schulprüfung überhaupt das Internet benutzen musst.
Wir nutzen in der Schule Lazaraus mit der Bibliothek ZEOS
Meinst Du Lazarus und ZeosLib?
- Table-Lock, Record-Lock und Exclusive-Lock.
Table-Lock wäre mir klar, da wird zum Beispiel bei "Auto Commit" die ganze Tabelle gesperrt, anstatt nur der Datendatz, an dem ich editiere.
Was jedoch wäre Record und Exclusive?
Wie sind typische Tabellen in relationalen Datenbanken organisiert? Enthalten sie etwa Datensätze? Was also wird bei einem Record-Lock gesperrt? Was, schätzt Du, ist einfacher? Was, schätzt Du, ist vermutlich (insbesondere) bei konkurrierendem Betrieb weniger störend?
Zu exklusiven Sperren findest Du hier bei SELFHTML Aktuell eine Erklärung: http://aktuell.de.selfhtml.org/artikel/programmiertechnik/dateisperren/gleichzeitige-zugriffe.htm#stufen.
Den Rest lasse ich außen vor, da Deine Informationen zum Kontext und Deinem Wissensstand viel zu dünn sind.
und ich frage mich was nun folgende Begriffe genau bedeuten
Ich frage mich, was Deine Fragen speziell mit Lazarus und ZeosLib zu tun haben?
Freundliche Grüße
Vinzenz
-
hi,
es wundert mich, dass Du für eine Schulprüfung überhaupt das Internet benutzen musst.
wir haben leider keinerlei infomaterial erhalten.
Wir nutzen in der Schule Lazaraus mit der Bibliothek ZEOS
Meinst Du Lazarus und ZeosLib?
- Table-Lock, Record-Lock und Exclusive-Lock.
Table-Lock wäre mir klar, da wird zum Beispiel bei "Auto Commit" die ganze Tabelle gesperrt, anstatt nur der Datendatz, an dem ich editiere.
Was jedoch wäre Record und Exclusive?
Wie sind typische Tabellen in relationalen Datenbanken organisiert? Enthalten sie etwa Datensätze? Was also wird bei einem Record-Lock gesperrt? Was, schätzt Du, ist einfacher? Was, schätzt Du, ist vermutlich (insbesondere) bei konkurrierendem Betrieb weniger störend?
Zu exklusiven Sperren findest Du hier bei SELFHTML Aktuell eine Erklärung: http://aktuell.de.selfhtml.org/artikel/programmiertechnik/dateisperren/gleichzeitige-zugriffe.htm#stufen.
danke für den link.
Den Rest lasse ich außen vor, da Deine Informationen zum Kontext und Deinem Wissensstand viel zu dünn sind.
und ich frage mich was nun folgende Begriffe genau bedeuten
Ich frage mich, was Deine Fragen speziell mit Lazarus und ZeosLib zu tun haben?
am beispiel lazarus mit der bibliothek ZeosLib haben wir in einer aufgabe die wörter Table-Lock, Record-Lock und Exclusive-Lock vorgedonnert bekommen.
bei table-lock meinte der proff, dass die ganze tabelle in der datenbank gesperrt ist, also ein anderen nutzer kein anderes datensatz von der gleichen tabelle bearbeiten kann. das wird womöglich dann das exclusive lock sein, wo man dann nur ein datensatz/row sperren kann. bleibt dann record lock.-
Hallo,
- Table-Lock, Record-Lock und Exclusive-Lock.
Table-Lock wäre mir klar, da wird zum Beispiel bei "Auto Commit" die ganze Tabelle gesperrt, anstatt nur der Datendatz, an dem ich editiere.
Was jedoch wäre Record und Exclusive?
Wie sind typische Tabellen in relationalen Datenbanken organisiert? Enthalten sie etwa Datensätze? Was also wird bei einem Record-Lock gesperrt? Was, schätzt Du, ist einfacher? Was, schätzt Du, ist vermutlich (insbesondere) bei konkurrierendem Betrieb weniger störend?
Zu exklusiven Sperren findest Du hier bei SELFHTML Aktuell eine Erklärung: http://aktuell.de.selfhtml.org/artikel/programmiertechnik/dateisperren/gleichzeitige-zugriffe.htm#stufen.
danke für den link.
Aber gerne doch. Dafür sind die Artikel da :-)
bei table-lock meinte der proff, dass die ganze tabelle in der datenbank gesperrt ist, also ein anderen nutzer kein anderes datensatz von der gleichen tabelle bearbeiten kann. das wird womöglich dann das exclusive lock sein,
Nein.
wo man dann nur ein datensatz/row sperren kann. bleibt dann record lock.
Ob man Table-Locking oder Record-Locking einsetzt, ist vor allem eine Frage, was das Datenbankmanagementsystem (genauer die verwendete Storage Engine) unterstützt. Table-Locking und Record-Locking geben an, *was* gesperrt wird. Für exklusive Sperren habe ich Dir nicht ohne Hintergedanken einen Artikel verlinkt, der mit Datenbanken nichts zu tun hat. Dass eine Sperre exklusiv ist, gibt das *wie* der Sperre an - und dies ist prinzipiell gesehen unabhängig davon, was gesperrt wird.
Freundliche Grüße
Vinzenz
-
Hi,
Aber gerne doch. Dafür sind die Artikel da :-)
vielen dank. dann noch etwas richtung abtraktionslayer. er meinte, man könne auf treiberebene programmieren, sprich von programmiersprache auf eine datenbank zugreifen.
das problem ist, wenn man die datenbank wechselt, müsse man den ganzen code anpassen, dafür gäbe es dann abtraktionslayers.und JDBC wäre zum beispiel ein abtraktionslayers. d.h., sollte man die datenbank ändern, müsse man nur eine funktion/wert/was auch immer in den jdbc einstellungen ändern, ohne den ganzen source code zu ändern.
wenn ich nun mit java programmiere und eine db verbindung aufbaue (da ist der mysql treiber eingebunden und JDBC auch) und im source codes viele selects und inserts habe und später die datenbank wechsle, dann ändere ich ja den JDBC oder irgendwelchen parameter bei jdbc, aber das problem ist ja, dass ich viele selects und inserts in meinen codes habe und die sind ja für alle datenbanken ja nicht gleich die notation, da muss ich ja dann trotzdem anpassungen im source code vornehmen
grüße
-
Hi!
dann noch etwas richtung abtraktionslayer. er meinte, man könne auf treiberebene programmieren, sprich von programmiersprache auf eine datenbank zugreifen.
das problem ist, wenn man die datenbank wechselt, müsse man den ganzen code anpassen, dafür gäbe es dann abtraktionslayers.
und JDBC wäre zum beispiel ein abtraktionslayers. d.h., sollte man die datenbank ändern, müsse man nur eine funktion/wert/was auch immer in den jdbc einstellungen ändern, ohne den ganzen source code zu ändern.Ja, diese Meinung existiert, das halte ich jedoch zum Großteil für einen Aberglauben. Das kann funktionieren, wenn man sich auf eine einfache SQL-Syntax beschränkt. Bei allem Weitergehenden kommt man schnell an die Grenzen, ab der man SQL-Dialekt-spezifische Dinge verwenden muss. Ein reiner Datenbankabstraktionslayer bringt schon eine Menge, aber muss an der Stelle passen, wenn es austauschbar sei soll.
Man kann weiter oben ansetzen und mit Objekt-Relation-Mappern hantieren. Dann hat man sich nur noch mit Objekten zu tun und der ORM kann sich um individuelle Syntaxprobleme beim Speichern und Lesen kümmern. Allerdings schränkt das auch die Flexibilität ein, wenn man spezielle Abfragen benötigt. Statt der umfänglichen Möglichkeiten von SQL im Allgemeinen und der Dialekte im Speziellen, hat man nur noch das was der ORM zur Verfügung stellt. Das mag eine Menge sein, aber nicht immer ausreichend. Dann ist man schnell bei Lösungen wie LINQ angekommen. Das simuliert quasi eine SQL-ähnliche Syntax, die aber auf der Ebene der Progammiersprache(n) beziehungsweise auf Framework-Ebene standardisiert ist. So kommt man gar nicht mehr in die Versuchung und die Gelegenheit, SQL-Dialekte selbst verwenden zu müssen. Hier ist man wieder flexibler als zuvor, aber kann immer noch nicht alle Feinheiten des DBMS ausnutzen. Und gerade die sind es, die man bei Entscheidungen für oder gegen ein bestimmtes System aus technischer Sicht berücksichtigen sollte. Wenn sich alle DBMSe gleich bedienen lassen, braucht man eigentlich nur noch den Preis zur Entscheidung heranzuziehen (etwas übertrieben. Systemwartung abseits der Anwendungen kommt ja auch noch hinzu). Abstraktionslayer sind in gewisser Weise nicht nur programmierfreundlicher sondern auch managementfreundlicher.
Und was auch noch bleibt, ist das Kapseln von speziellen Aufgaben in Stored Procedures. Die sollte ein guter ORM neben dem Objekt-Zugriff auch noch bieten. Hier kann man dann doch wieder alles ausnutzen, was das DBMS bietet. Muss dann aber auch bei einem Wechsel dies Routinen in den neuen Dialekt umschreiben.
wenn ich nun mit java programmiere und eine db verbindung aufbaue (da ist der mysql treiber eingebunden und JDBC auch) und im source codes viele selects und inserts habe und später die datenbank wechsle, dann ändere ich ja den JDBC oder irgendwelchen parameter bei jdbc, aber das problem ist ja, dass ich viele selects und inserts in meinen codes habe und die sind ja für alle datenbanken ja nicht gleich die notation, da muss ich ja dann trotzdem anpassungen im source code vornehmen
Bei einfachen Statements ist das noch problemlos. Die unterschiedliche Syntax, was die Stringbegrenzer anbelangt, bekommt man durch Funktionen im Layer oder durch konsequenten Einsatz von Prepared Statements gelöst.
Lo!
-
yo,
und JDBC wäre zum beispiel ein abtraktionslayers. d.h., sollte man die datenbank ändern, müsse man nur eine funktion/wert/was auch immer in den jdbc einstellungen ändern, ohne den ganzen source code zu ändern.
Ja, diese Meinung existiert, das halte ich jedoch zum Großteil für einen Aberglauben. Das kann funktionieren, wenn man sich auf eine einfache SQL-Syntax beschränkt. Bei allem Weitergehenden kommt man schnell an die Grenzen, ab der man SQL-Dialekt-spezifische Dinge verwenden muss.
ich will mich dem vom dedlfix gesagten anschließen, bzw. noch einen schritt weiter gehen. meine java entwickler sahen die datenbank eigentlich nur noch als eine hilfsmittel an, daten dauerhaft zu speichern. für mich ist sie weit mehr, nämlich ein konzept, dass möglichst alle relevanten daten eines unternehmens an einer stelle bündelt und in eine gemeinsame form bringt und zwar applikationsunäbhängig. aus meiner sicht sind es also nicht die daten, die transparent aus verschiedenen quellen gewonnen werden, sondern es sind die applikationen, die transparent für die datenbank sind. aber darüber kann man wohl vortrefflich streiten....
Ilja
-
hi,
vielen dank euch allen.
1. Also kurz gesagt, wenn ich jdbc in meinen java code eingebunden habe, sprich jdbc als abtraktionslayer benutze, so könnte ich einfach den parameter von mysql auf ne orakle oder postgres datenbank ändern oder? (falls jdbc das überhaupt unterstützt)
2. 1-1 Verbindungen in Datenbanken machen zu 99% nie sinn. wo gäbe es kurz erklärt einen Sinn bei den 1%? (Wenn man ein Abbild von einer Tabelle auf eine andere Tabelle macht? Oder, Ein Abbild/Kombination von mehreren Tabellen und dann per Unique die Kombinationen angibt?)
3. Wie würden ihr kurz die DBMS erklären? In Schnittstelle zwischen DB und Anwendung, welches SQL-Syntax zur Verfügung stellt?
4. Habt ihr Praxis oft in etwa solche Fälle, wo in einer Zwischentabelle eine FremdID drin ist in eine Spalte, die je nach Fall für eine Tabelle1, Tabelle2 oder Tabelle3 gilt. Müsste dann softwareseitig gecheckt werden, welche von den 3 Tabellen mit der FremdID abgesprochen werden muss. Hoffentlich konnte ich den Fall halbwegs gut erklären.
Ich denke ich bin weitestgehenst fit, wird schon ausreichen :-))))))
-
Hallo,
- 1-1 Verbindungen in Datenbanken machen zu 99% nie sinn.
das sehe ich anders. 1:1-Beziehungen zwischen Tabellen sind oft sinnvoll.
wo gäbe es kurz erklärt einen Sinn bei den 1%?
1:1-Beziehungen sind für "is a"-Fälle ganz gut, sprich um die Probleme von Frage 4 zu eliminieren, d.h. in 99% aller Fälle sind sie sinnvoll.
- Wie würden ihr kurz die DBMS erklären? In Schnittstelle zwischen DB und Anwendung, welches SQL-Syntax zur Verfügung stellt?
Nein. Ein Datenbankmanagementsystem ist keine Schnittstelle, es bietet Schnittstellen.
- Habt ihr Praxis oft in etwa solche Fälle, wo in einer Zwischentabelle eine FremdID drin ist in eine Spalte, die je nach Fall für eine Tabelle1, Tabelle2 oder Tabelle3 gilt.
Diese Fälle lassen sich ganz einfach abhandeln, indem man eine 1:1-Beziehung nutzt.
Freundliche Grüße
Vinzenz
-
Hi!
- Also kurz gesagt, wenn ich jdbc in meinen java code eingebunden habe, sprich jdbc als abtraktionslayer benutze, so könnte ich einfach den parameter von mysql auf ne orakle oder postgres datenbank ändern oder? (falls jdbc das überhaupt unterstützt)
Wenn man das genau definieren will, sage ich, dass das kein Datenbankabstraktionslayer sondern ein Datenbank_zugriffs_abstraktionslayer ist. JDBC vereinheitlicht den generellen Zugriff, nicht aber den konkreten Umgang in Form von SQL-Statements.
Und selbst wenn man mal die SQL-Dialekte außer Acht lässt, muss man beim Programmieren gegen diesen Datenbank_zugriffs_abstraktionslayer noch Unterschiede in den Systemen berücksichtigen, so es da nicht eine vereinheitlichende Empfehlung gibt, aufgrund der die unterschiedlichen Verhaltensweisen (und sei es durch Simulation auf einigen Systemen) ausgeglichen werden. Konkrete Beispiele: Prepared Statements lassen sich üblicherweise problemlos simulieren. Autoincrement-Werte versus Sequenzen ist problematischer. Autoincrement-Werte (MySQL, MS-SQL) stehen nach einem Datensatzeinfügen zur Verfügung, bei Sequenzen (Oracle) muss man vorher den neuen Wert abfragen (oder diese Abfrage ins SQL-Statement einbauen). Sequenzen müssen in Oracle extra angelegt werden. Wenn man das in MySQL simulieren will, braucht man eine weitere Tabelle (oder eine für alle Sequenzen). Will man also da eine Vereinheitlichung reinbringen, muss man sich auf eine Vorgehensweise festlegen und die jeweils für andere Systeme simulieren.
Ich denke ich bin weitestgehenst fit, wird schon ausreichen :-))))))
Nur nicht in Rechtschreibung :-) "weitestgehend"
Lo!
-
moin,
bei Sequenzen (Oracle) muss man vorher den neuen Wert abfragen (oder diese Abfrage ins SQL-Statement einbauen).
als ergänzung, wir haben es über trigger gesteuert, so dass du die spalte des primarykey gar nicht mehr bei einem insert angeben muss. wenn man es nicht über trigger steuert, braucht man die sequenz weder vorher abfragen noch in einer ganzen abfrage einbinden. es reicht, wenn man im INSERT statement die sequenz mit ihren objektnamen in form von SEQUENZ_NAME.NEXTVAL anspricht.
Ilja
-
Hi!
bei Sequenzen (Oracle) muss man vorher den neuen Wert abfragen (oder diese Abfrage ins SQL-Statement einbauen).
[...] es reicht, wenn man im INSERT statement die sequenz mit ihren objektnamen in form von SEQUENZ_NAME.NEXTVAL anspricht.Genauso meinte ich das. Das Problem ist nur, dass es irgendwer ins Statement einbauen muss (wenn man es nicht über Trigger macht). Und da das Oracle-spezifisch ist, ist schonmal wieder weniger Austauschbarkeit gegeben. Es sei denn, die Datenbankabstraktionsschicht (diesmal ohne "zugriffs") modifiziert das da rein. (Oder man nimmt eben die Trigger-Lösung.)
Lo!
-
-
-
-
-
- Table-Lock, Record-Lock und Exclusive-Lock.
- Table-Lock, Record-Lock und Exclusive-Lock.
- Table-Lock, Record-Lock und Exclusive-Lock.