Hi zusammen, ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund, die komplexe Abfragen ermöglicht. Automatisch fällt also das windows-typische C:\ D:\ etc. weg. Wie genau es aussehen wird, weiß ich nicht, aber wenn es so ist, wie ich es mir vorstelle, dürfte es durchaus innovativ und von der Struktur den Linuxdateisystemen überlegen sein. Meine Vorstellung ist, dass es keine Verzeichnisse mehr gibt, sondern einfach Dateien, die sortiert dargestellt werden können. Nach Autor, Titel etc. Folgende Abfragen wären möglich: Liste alle Dokumente auf, die ich in den letzten 5 Tagen erstellt habe und auf die von den Programmen X, Y und Z zugriffen wurde. Oder: Lege aus den Bildern vom 10-12.11.02, die von den Usern X und Y gesehen wurden eine Bildergalerie an. Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend. Verzeichnisse verwirren Anfänger immer wieder. Wenn man so einfach alle Dateien sortiert und strukturiert, je nach Art der Abfrage aufgelistet bekommen würde, hätten die wenigstens Probleme einen PC zu bedienen. Was haltet ihr von dem neuen Dateisystem, oder der Idee prinzipiell? Wäre so etwas nicht etwas revolutionäres, was sich auch Linux zu eigen machen könnte? Mike
Am Sam, 2002-12-07 um 20.34 schrieb Michael Gebhart:
Hi zusammen,
ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund, die komplexe Abfragen ermöglicht. Automatisch fällt also das windows-typische C:\ D:\ etc. weg. Wie genau es aussehen wird, weiß ich Laufwerke und Pfade wird es weiter geben, weil sonst würde ja keine alte Software drauf laufen. Soweit ich weiss braucht man unter Windows auch keine Laufwerke mehr, es gibt schon lange eine eigene Notation ohne Laufwerksbuchstaben. Zumindest bei Netzwerkshares. Ausserdem muss dazu noch ein Datenbankserver laufen, was nicht gerade sehr performant ist. Naja, viel Vergnügen beim Suchen der Dateien...
-- Fritz "der mit dem Linux tanzt" Ganter http://www.kraftvoll.at Key fingerprint = 555A DDBB 3985 16FF CD41 2031 C485 1783 BF34 728F
Hallo, On Sat, 07 Dec 2002, Michael Gebhart wrote:
ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund,
Mit MS-SQL? *muhahaha*
Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend. Verzeichnisse verwirren Anfänger immer wieder. Wenn man so einfach alle Dateien sortiert und strukturiert, je nach Art der Abfrage aufgelistet bekommen würde, hätten die wenigstens Probleme einen PC zu bedienen.
Und wie soll es dann ablaufen, wenn du Dateien abspeicherst? Willst du alles einfach auf den Desktop knallen? Oder halt "irgendwo hin"? Womoeglich im Internet-Cache der regelmaessig geloescht wird? Na denn viel Spass! Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an... Achso, den Festplattenherstellern duerfte das natuerlich gefallen, endlich eine Anwendung, die die neuen Kapazitaeten auslastet. 100 MB Daten, 500 MB Metadaten *rotfl*.
Was haltet ihr von dem neuen Dateisystem, oder der Idee prinzipiell? Wäre so etwas nicht etwas revolutionäres, was sich auch Linux zu eigen machen könnte?
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht. Achso: Was "Anfaenger" verwirrt sind schlicht unpassende Analogien, wenn "man" versucht ihnen das zu erklaeren. Je nach "Hintergrund" der Person sind eben unterschiedliche Analogien angebracht. Schwieriger wird's erst bei der Unix-spezifischen Variante "alles ist eine Datei" (also insbesondere auch Verzeichnisse, Devices (wie Festplatten!) usw. aber das kann man "rausschieben"). Ansonsten kann man sich meist wunderbar mit der "Buero"-Analogie behelfen und Verzeichnisse sind einfach Aktenordner und -schraenke ;) CPU&-Register: die Person (mit Kurzzeitgedaechnis) L1-Cache: Schreibtischoberflaeche/-unterlage L2-Cache: Ablagefaecher auf dem Schreibtisch RAM: Regale/Aktenschraenke im Arbeitszimmer Festplatte: Archiv im Keller Tapes etc: Backup-Archiv in $FILIALE / $BANK o.ae. Und "Verzeichnisse" sind also schlicht ein "Ordnungsmittel" wie Hefter/Ordner/Schraenke, in die man "Akten" (-blaetter) einsortieren kann. -dnh, (*looking at sig*) ooh, shiny! Good sigmonster, have a Lebkuchen! [1] wieso zum Henker schreiben seit der Linksschreibdeform eingentlich so viele "Albtraum"? *HRMPF* -- If Bill Gates had a nickle for every time Windows crashed... Oh, wait, he does! - from a slashdot.org post
Moin,
* David Haller
On Sat, 07 Dec 2002, Michael Gebhart wrote:
ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund,
Mit MS-SQL? *muhahaha*
Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend. Verzeichnisse verwirren Anfänger immer wieder. Wenn man so einfach alle Dateien sortiert und strukturiert, je nach Art der Abfrage aufgelistet bekommen würde, hätten die wenigstens Probleme einen PC zu bedienen.
Und wie soll es dann ablaufen, wenn du Dateien abspeicherst? Willst du alles einfach auf den Desktop knallen? Oder halt "irgendwo hin"? Womoeglich im Internet-Cache der regelmaessig geloescht wird? Na denn viel Spass!
Klar kommt das 'irgendwo hin', genauso wie das jetzt 'irgendwo hin' gespeichert wird. Wenn man klug ist, macht man heute noch ein paat Angaben wie den Verzeichnisnamen, etwas entsprechendes kann man aber sogar besser bei einem DBFS angeben. (Womit wir wieder halbwegs bei erweiterten Attributen wären.)
Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...
Huh? Seit wann sind RDBMS dafür bekannt, mit Daten besonders schlampig umzugehen?
Achso, den Festplattenherstellern duerfte das natuerlich gefallen, endlich eine Anwendung, die die neuen Kapazitaeten auslastet. 100 MB Daten, 500 MB Metadaten *rotfl*.
Irgendwas ist ja immer.
Was haltet ihr von dem neuen Dateisystem, oder der Idee prinzipiell? Wäre so etwas nicht etwas revolutionäres, was sich auch Linux zu eigen machen könnte?
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.
Es wird unter Garantie auch ein Dateisystemfrontend geben, sonst könnte man ja alle alten Anwendungen in die Tonne schmeißen.
Achso: Was "Anfaenger" verwirrt sind schlicht unpassende Analogien, wenn "man" versucht ihnen das zu erklaeren. Je nach "Hintergrund" der Person sind eben unterschiedliche Analogien angebracht. Schwieriger wird's erst bei der Unix-spezifischen Variante "alles ist eine Datei" (also insbesondere auch Verzeichnisse, Devices (wie Festplatten!) usw. aber das kann man "rausschieben"). Ansonsten kann man sich meist wunderbar mit der "Buero"-Analogie behelfen und Verzeichnisse sind einfach Aktenordner und -schraenke ;)
CPU&-Register: die Person (mit Kurzzeitgedaechnis) L1-Cache: Schreibtischoberflaeche/-unterlage L2-Cache: Ablagefaecher auf dem Schreibtisch RAM: Regale/Aktenschraenke im Arbeitszimmer Festplatte: Archiv im Keller
Na, so oft gehe ich nicht in den Keller. Da würde ich eher die Caches weglassen, die sind eh nur technisches Detail. CPU&-Register: die Person (mit Kurzzeitgedaechnis) RAM: Schreibtischoberflaeche/-unterlage Festplatte: Regale/Aktenschraenke im Arbeitszimmer
Und "Verzeichnisse" sind also schlicht ein "Ordnungsmittel" wie Hefter/Ordner/Schraenke, in die man "Akten" (-blaetter) einsortieren kann.
Oder wie beliebige Kriterien, die man dem DBFS mitgeben kann. Thorsten -- If people could put rainbows in zoos, they'd do it. - Hobbes
Hallo, On Mon, 09 Dec 2002, Thorsten Haude wrote:
Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...
Huh? Seit wann sind RDBMS dafür bekannt, mit Daten besonders schlampig umzugehen?
man M$SQL? (kann das eigentlich transactions?) Und hast du schonmal aus den (binaer) Daten einer DB (z.B. mysql) ein .tex wiederhergestellt? Schau doch einfach (via /dev/hdXY im hexeditor!) mal in dein /var/lib/mysql und finde dort eine bestimmte Mail/ein .tex o.ae... Und dann sabotiere mal einen zufaelligen Sektor der HD auf der die DB (-datei) liegt... Viel Spass auch... (Achso, du darfst statt mysql auf ext2/ext3 gerne eine andere DB mit Speicherung im raw-Modus auf $DEVICE verwenden.) Ohne ein _zuverlaessiges_ mind. _taegliches_ Backup kannst du statt der DB (naja, fast) auch gleich /dev/null verwenden. Und du willst mir doch nicht weis machen, dass das $JOE_RANDOM_LUSER kaufen und (richtig!) verwenden wuerde, oder?
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.
Es wird unter Garantie auch ein Dateisystemfrontend geben, sonst könnte man ja alle alten Anwendungen in die Tonne schmeißen.
Jaja. So ein gutes wie das "Suchen" Dingens von Win9x... [Analogie]
Na, so oft gehe ich nicht in den Keller. Da würde ich eher die Caches weglassen, die sind eh nur technisches Detail.
CPU&-Register: die Person (mit Kurzzeitgedaechnis) RAM: Schreibtischoberflaeche/-unterlage Festplatte: Regale/Aktenschraenke im Arbeitszimmer
Jo, passt auch. Aber ich wuerde schon den Keller nehmen. Das verdeutlicht den Geschwindigkeitsunterschied besser ;) -dnh -- Versäumen sie nicht den neuen Film von Albert B. Blumenkohl ---===### "To live and let rub" ###===--- Aus dem Inhalt: "Mein Name ist Gross. Flo Gross. Mein Schlauch auch. Geben Sie mir eine Kampflesbe bitte, eine gerührte. Nein, geschüttelt. Wo ich sie doch viel lieber gerieben hätte." [Sig von 'Moss' in suse-talk]
Moin,
* David Haller
On Mon, 09 Dec 2002, Thorsten Haude wrote:
Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...
Huh? Seit wann sind RDBMS dafür bekannt, mit Daten besonders schlampig umzugehen?
man M$SQL? (kann das eigentlich transactions?)
Ich kann mir nicht vorstellen, daß MS-SQL so schlecht ist wie sein Ruf in dieser Liste.
Und hast du schonmal aus den (binaer) Daten einer DB (z.B. mysql) ein .tex wiederhergestellt? Schau doch einfach (via /dev/hdXY im hexeditor!) mal in dein /var/lib/mysql und finde dort eine bestimmte Mail/ein .tex o.ae... Und dann sabotiere mal einen zufaelligen Sektor der HD auf der die DB (-datei) liegt... Viel Spass auch...
Von RDBMS war die Rede, nicht von MySQL.
Ohne ein _zuverlaessiges_ mind. _taegliches_ Backup kannst du statt der DB (naja, fast) auch gleich /dev/null verwenden. Und du willst mir doch nicht weis machen, dass das $JOE_RANDOM_LUSER kaufen und (richtig!) verwenden wuerde, oder?
Stell Dir vor, die Speicherung der Daten könnte man tatsächlich ändern, wenn RDBMS und JFS zusammen entwickelt werden, um eine gemeinsame Aufgabe zu erfüllen.
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.
Es wird unter Garantie auch ein Dateisystemfrontend geben, sonst könnte man ja alle alten Anwendungen in die Tonne schmeißen.
Jaja. So ein gutes wie das "Suchen" Dingens von Win9x...
Unter Windows, ja. Unter Unix würde es weiterhin find und grep geben. Thorsten -- He who passively accepts evil is as much involved in it as he who helps to perpetrate it. He who accepts evil without protesting against it is really cooperating with it. - Martin Luther King
On Die, 10 Dez 2002 at 10:13 (+0100), Thorsten Haude wrote:
* David Haller
[02-12-10 00:28]: On Mon, 09 Dec 2002, Thorsten Haude wrote:
Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...
Huh? Seit wann sind RDBMS dafür bekannt, mit Daten besonders schlampig umzugehen?
man M$SQL? (kann das eigentlich transactions?)
Ich kann mir nicht vorstellen, daß MS-SQL so schlecht ist wie sein Ruf in dieser Liste.
ACK. Der Ruf hier ist ja auch größtenteils auf Emotionen und *habe ich mal einen gekannt, der jemanden getroffen hat, der schon mal ein MS-SQL Handbuch in der Hand hatte* begründet :-( Ja, der MS-SQL-Server kennt Transaktionen, seit IIRC 6.5 Row Level Locking, Berechtigungskonzept, Replikation, Trigger + Stored Procedures, referentielle Integrität, Inline-Selects, Outer Joins usw. Das Ding wird von vielen professionellen Anwendungen (ERP, Archivierung z. B.) genutzt. Jan
Thorsten Haude schrieb am 10.12.2002 um 10:13:18 +0100: Hallo Thorsten,
* David Haller
[02-12-10 00:28]: On Mon, 09 Dec 2002, Thorsten Haude wrote:
Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...
Huh? Seit wann sind RDBMS dafür bekannt, mit Daten besonders schlampig umzugehen?
man M$SQL? (kann das eigentlich transactions?)
ja.
Ich kann mir nicht vorstellen, daß MS-SQL so schlecht ist wie sein Ruf in dieser Liste.
ist er auch nicht. Aber dies ist eine Linuxliste. Da darf Software von MS nicht gut sein, bzw. ist Software von MS prinzipiel schlecht. Auch wenn genau das Gegenteil der Fall ist :-)
Und hast du schonmal aus den (binaer) Daten einer DB (z.B. mysql) ein .tex wiederhergestellt? Schau doch einfach (via /dev/hdXY im hexeditor!) mal in dein /var/lib/mysql und finde dort eine bestimmte Mail/ein .tex o.ae... Und dann sabotiere mal einen zufaelligen Sektor der HD auf der die DB (-datei) liegt... Viel Spass auch...
Von RDBMS war die Rede, nicht von MySQL.
da gilt wohl das selbe wie oben geschrieben. Da redet jemand über MS-Software, also ist das schlecht. Und darüber gibt es auch garnichts zu diskutieren :-)
Ohne ein _zuverlaessiges_ mind. _taegliches_ Backup kannst du statt der DB (naja, fast) auch gleich /dev/null verwenden. Und du willst mir doch nicht weis machen, dass das $JOE_RANDOM_LUSER kaufen und (richtig!) verwenden wuerde, oder?
Seine Daten ohne Backup irgendeinem Dateisystem anzuvertrauen ist immer mit einer Tendenz zu /dev/null zu sehen. Backups gehören halt dazu, egal was oder wer meine Daten bereithält. Oder glaubst Du etwa irgendeine Versicherung (oder was auch immer) hält aus Datenrettungsgründen seine Daten nur auf einer Platte die ext3 formatiert ist? Weil man die ja mit einem Editor nach einem Absturz bearbeiten kann :-)
Stell Dir vor, die Speicherung der Daten könnte man tatsächlich ändern, wenn RDBMS und JFS zusammen entwickelt werden, um eine gemeinsame Aufgabe zu erfüllen.
wenn ich mit einer vernünftigen DB arbeite, ist das Journalling doch quasi schon dabei.
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.
warum? Meinst Du nur weil es Dinge schon gibt, darf es keinen neuen, vieleicht besseren Ansatz geben? Wenn es danach geht, würden wir heute alle noch auf Bäumen sitzen und Bananen fressen. Oder darf das bessere nur nicht von MS kommen? Mich hätte mal interessiert was passiert wäre, wenn in der Ausgangsmail nicht MS, sondern SuSE o. Redhat o. Debian o. ... gestanden hätte. Dann währe das mit Sicherheit eine verdammt coole Sache gewesen. Bis denne, Michael -- ---------------------------------------------------------- Michael Schulz, Institut f. Geophysik, Universität Münster Corrensstr. 24, 48149 Münster Tel.: 0251-8333938, e-mail: michael@earth.uni-muenster.de
Hallo, On Wed, 11 Dec 2002, Michael Schulz wrote:
Thorsten Haude schrieb am 10.12.2002 um 10:13:18 +0100:
* David Haller
[02-12-10 00:28]: Und hast du schonmal aus den (binaer) Daten einer DB (z.B. mysql) ein .tex wiederhergestellt? Schau doch einfach (via /dev/hdXY im hexeditor!) mal in dein /var/lib/mysql und finde dort eine bestimmte Mail/ein .tex o.ae... Und dann sabotiere mal einen zufaelligen Sektor der HD auf der die DB (-datei) liegt... Viel Spass auch...
Von RDBMS war die Rede, nicht von MySQL.
Nimm eine beliebige RDBMS, mir egal. Ueberschreib der mal einen "passenden" Sektor in den Daten und schau wie das Teil dann noch laeuft...
da gilt wohl das selbe wie oben geschrieben. Da redet jemand über MS-Software, also ist das schlecht. Und darüber gibt es auch garnichts zu diskutieren :-)
Jetzt unterstellst du mir was.
Seine Daten ohne Backup irgendeinem Dateisystem anzuvertrauen ist immer mit einer Tendenz zu /dev/null zu sehen. Backups gehören halt dazu, egal was oder wer meine Daten bereithält.
Mach mal den "Sektortest". Ist bei der DB dann nur dieser Sektor weg? Oder mehr? Bei ext2/ext3 ist nur der eine Sektor im Eimer (bei FAT uebrigens auch). [das schrieb auch ich:]
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.
warum? Meinst Du nur weil es Dinge schon gibt, darf es keinen neuen, vieleicht besseren Ansatz geben?
Unfug. Ich finde die Idee (aus den geschilderten Gruenden) schlecht. Also wuerde ich's nicht verwenden. Was andere machen geht mir weitestgehend am Sitzfleisch vorbei.
Oder darf das bessere nur nicht von MS kommen?
Duerfen schon. Aber der Win-featuritis zwanghaft nachzuaeffen halte ich fuer toericht. Bin mal gespannt, ob da jemand TCPA/Palladium nachbasteln will, is ja auch von Billy...
Mich hätte mal interessiert was passiert wäre, wenn in der Ausgangsmail nicht MS, sondern SuSE o. Redhat o. Debian o. ... gestanden hätte.
Das haette meine Meinung nicht geaendert.
Dann währe das mit Sicherheit eine verdammt coole Sache gewesen.
*vgb* :-) Ähm, [diverse Vorschlaege] >>>_v_oll _b_ekifft _g_rins? So, wie Tux? > Ich schätze, ich könnte kiffen soviel ich will, ich werde
Nein. -dnh -- trotzdem nie _so_ grinsen... Tja, jeder grinst halt, wie ihm der Schnabel gewachsen ist. [in suse-talk]
Moin,
* David Haller
On Wed, 11 Dec 2002, Michael Schulz wrote:
Thorsten Haude schrieb am 10.12.2002 um 10:13:18 +0100:
* David Haller
[02-12-10 00:28]: Und hast du schonmal aus den (binaer) Daten einer DB (z.B. mysql) ein .tex wiederhergestellt? Schau doch einfach (via /dev/hdXY im hexeditor!) mal in dein /var/lib/mysql und finde dort eine bestimmte Mail/ein .tex o.ae... Und dann sabotiere mal einen zufaelligen Sektor der HD auf der die DB (-datei) liegt... Viel Spass auch...
Von RDBMS war die Rede, nicht von MySQL.
Nimm eine beliebige RDBMS, mir egal. Ueberschreib der mal einen "passenden" Sektor in den Daten und schau wie das Teil dann noch laeuft...
Du glaubst, man würde dieses Konzept realisieren, indem man $RDBMS installiert, einen FS-Wrapper darumpackt und es dabei belässt? Thorsten -- The only thing necessary for the triumph of evil is for the good men to do nothing. - Edmund Burke
* David Haller schrieb am 07.Dez.2002:
On Sat, 07 Dec 2002, Michael Gebhart wrote:
ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund,
Mit MS-SQL? *muhahaha*
Sicherlich kein MS-SQL und auch kein MySQL. Wenn Datenbank, dann was vernünftiges. Oracle oder DB2 oder so. Aber da fängt das Problem schon an. Wenn man es Professionell einsetzt, als damit Geld machen will, dann will Oracle und wahrscheinlich auch IBM, für ihre Datenbank sehr, sehr viel Geld. Abgesehen davon ist SQL eine *kotzwürg* Sprache. Mir hat noch keiner erklären können, warum die Syntax für ein UPDATE so total anders ist als die Syntax für ein INSERT. Und warum z.B AND einmal, wie bei vielen anderen Sprachen, als logisches und, und zum anderen als Aufzähltrenner, wo andere Sprachen ein Komma nehmen, verwendet wird.
Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend.
Bei UNIX gibt es schon seit ewigen Zeiten keine Laufwerkbuchstaben. Das ist nun wirklich nichts Neues.
Verzeichnisse verwirren Anfänger immer wieder.
Anfänger sind immer verwirrt.
Wenn man so einfach alle Dateien sortiert und strukturiert, je nach Art der Abfrage aufgelistet bekommen würde, hätten die wenigstens Probleme einen PC zu bedienen.
Kann man doch mit find und meinetwegen sort.
Und wie soll es dann ablaufen, wenn du Dateien abspeicherst? Willst du alles einfach auf den Desktop knallen? Oder halt "irgendwo hin"? Womoeglich im Internet-Cache der regelmaessig geloescht wird? Na denn viel Spass!
Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...
Ich kann mir schon ein Datenbankbasiertes Dateisystem vorstellen. Aber das wird, für den Anfänger mit Sicherheit nicht einfacher, als ein hirachisches.
Achso, den Festplattenherstellern duerfte das natuerlich gefallen, endlich eine Anwendung, die die neuen Kapazitaeten auslastet. 100 MB Daten, 500 MB Metadaten *rotfl*.
Nun ja, sehr viele Dateien verbraten mehr I-Node, als tatsächliche Daten. Ich weiß auch nicht, warum ein Datenbankorientiertes System soviel Overhead produzieren sollte.
Was haltet ihr von dem neuen Dateisystem, oder der Idee prinzipiell? Wäre so etwas nicht etwas revolutionäres, was sich auch Linux zu eigen machen könnte?
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.
locate brauche ich nur sehr selten. Da kann man ja nur nach den Namen suchen, nicht aber nach Datum, Größe, oder was auch immer. find kann das, braucht aber ewig, besonders wenn nach Inhalt gesucht wird. ;)
Achso: Was "Anfaenger" verwirrt sind schlicht unpassende Analogien, wenn "man" versucht ihnen das zu erklaeren. Je nach "Hintergrund" der Person sind eben unterschiedliche Analogien angebracht. Schwieriger wird's erst bei der Unix-spezifischen Variante "alles ist eine Datei" (also insbesondere auch Verzeichnisse, Devices (wie Festplatten!) usw. aber das kann man "rausschieben").
Was ist denn daran schwierig? Ist doch viel einfacher als alles andere. Klar, daß eine Festplatte eine Datei ist, muß man vielleicht schon mal schlucken. Wenn man rm /dev/hdd macht, ist dann die Festplatte schon aus dem Rechner verschwunden? Und hat man mit einem mknod /dev/sda eine schicke SCSI-Platte? (leider nein) ;)) Aber Grundsätzlich, wenn einem sowas als nicht einfach erscheint, dann kann ich mir das nur durch verbildung durch andere OS erklären.
Ansonsten kann man sich meist wunderbar mit der "Buero"-Analogie behelfen und Verzeichnisse sind einfach Aktenordner und -schraenke ;)
CPU&-Register: die Person (mit Kurzzeitgedaechnis)
Ich darf doch schwer bitten. Wenn ich morgens aufwache, brauche ich nicht erst Aktenordner durchzulesen. Ich kann mich auch so erinnern.
L1-Cache: Schreibtischoberflaeche/-unterlage L2-Cache: Ablagefaecher auf dem Schreibtisch RAM: Regale/Aktenschraenke im Arbeitszimmer Festplatte: Archiv im Keller Tapes etc: Backup-Archiv in $FILIALE / $BANK o.ae.
Und "Verzeichnisse" sind also schlicht ein "Ordnungsmittel" wie Hefter/Ordner/Schraenke, in die man "Akten" (-blaetter) einsortieren kann.
Ganz generell, Linux ist nicht nur für Anfänger geschrieben. Ganz im Gegenteil. Linux gibt es auch im hochprofessionellen Einsatz. Etwa auf Middlewarerechner bei Banken, oder auf Rechner von Provider. Da werden ganz andere Anforderungen gestellt, als leicht Verständlichkeit. Es hat doch neulich mal einer richtig geschrieben, Linux ist nicht nur für Leute, die von links nach rechts schreiben. Linux ist auch für einen Rechner, der die Geldautomaten einer japanischen Kleinstadt überwacht und die Daten am Host weitergibt und von einem blinden Japaner über eine Braillezeile administriert wird. Diese Anforderungen werden nicht mit ein paar GUI-Elemente erfüllt. (Wie stellt man ein GUI eigentlich auf einer Braillezeile dar?) Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
Moin,
* Bernd Brodesser
* David Haller schrieb am 07.Dez.2002:
On Sat, 07 Dec 2002, Michael Gebhart wrote:
ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund,
Mit MS-SQL? *muhahaha*
Sicherlich kein MS-SQL und auch kein MySQL.
Sicherlich wird es MS-SQL sein, was denn sonst?
Abgesehen davon ist SQL eine *kotzwürg* Sprache. Mir hat noch keiner erklären können, warum die Syntax für ein UPDATE so total anders ist als die Syntax für ein INSERT. Und warum z.B AND einmal, wie bei vielen anderen Sprachen, als logisches und, und zum anderen als Aufzähltrenner, wo andere Sprachen ein Komma nehmen, verwendet wird.
Man kann jedenfalls mit SQL eine Menge Sachen machen, die mit einem nackten Dateisystem mühsamer wären. Allerdings geht es hier vermutlich auch eher um das RDBMS als um das Frontend. Thorsten -- Getting a thrill out of some stupid quote is a sign of idiocy. - turmeric
* Thorsten Haude schrieb am 09.Dez.2002:
Moin,
* Bernd Brodesser
[02-12-09 09:14]: * David Haller schrieb am 07.Dez.2002:
On Sat, 07 Dec 2002, Michael Gebhart wrote:
ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund,
Mit MS-SQL? *muhahaha*
Sicherlich kein MS-SQL und auch kein MySQL.
Sicherlich wird es MS-SQL sein, was denn sonst?
Abgesehen davon ist SQL eine *kotzwürg* Sprache. Mir hat noch keiner erklären können, warum die Syntax für ein UPDATE so total anders ist als die Syntax für ein INSERT. Und warum z.B AND einmal, wie bei vielen anderen Sprachen, als logisches und, und zum anderen als Aufzähltrenner, wo andere Sprachen ein Komma nehmen, verwendet wird.
Man kann jedenfalls mit SQL eine Menge Sachen machen, die mit einem nackten Dateisystem mühsamer wären. Allerdings geht es hier vermutlich auch eher um das RDBMS als um das Frontend.
Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend? Natürlich geht es um das RDBMS und das sollte doch professionell sein, die höchsten Anforderungen erfüllen. Es hat doch keinen Sinn, wenn man für höhere Ansprüche ein weiteres DBMS auf der Platte bräuchte. Wenn man schon alles neu macht, warum denn nicht gleich ein OODBMS? Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Moin,
* Bernd Brodesser
Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?
Irgendwie schon, die Datenbankengine heißt Jet.
Natürlich geht es um das RDBMS und das sollte doch professionell sein, die höchsten Anforderungen erfüllen. Es hat doch keinen Sinn, wenn man für höhere Ansprüche ein weiteres DBMS auf der Platte bräuchte.
Ich glaube, wir haben hier ein Mißverständnis. Ich spreche hier von Windows, Du offensichtlich nicht. Für Linux gibt es PostgreSQL, das ist wohl das beste System, das es zur Zeit für diesen Zweck gibt. Thorsten -- The liberty of a democracy is not safe if the people tolerate the growth of private power to the point where it becomes stronger than the democratic state itself. That in its essence is fascism - ownership of government by an individual, by a group or any controlling private power. - Franklin D. Roosevelt
* Thorsten Haude schrieb am 09.Dez.2002:
* Bernd Brodesser
[02-12-09 12:20]:
Natürlich geht es um das RDBMS und das sollte doch professionell sein, die höchsten Anforderungen erfüllen. Es hat doch keinen Sinn, wenn man für höhere Ansprüche ein weiteres DBMS auf der Platte bräuchte.
Ich glaube, wir haben hier ein Mißverständnis. Ich spreche hier von Windows, Du offensichtlich nicht.
Nein. Ich wußte nicht, daß Microsoft sowas in der Richtung vor hat, wie ich aus anderen Postings entnehmen kann. Ich habe auch nicht genau verstanden, was sie wollen, und ich glaube, ich will es auch gar nicht. Ich habe hier nur ganz allgemein gesprochen, ob für alle Zeiten ein hirachisches Dateisystem sein muß, oder etwa durch ein Datenbankfundiertes ersetzt werden kann.
Für Linux gibt es PostgreSQL, das ist wohl das beste System, das es zur Zeit für diesen Zweck gibt.
Für welchen Zweck? Entweder ich nehme ein DBMS, daß ruhigen Gewissens auch meine Bank auf ihren Host laufen läßt, um mein Geld zu verwalten, oder ich lasse es ganz bleiben. MySQL ist ja gut und schön, wenn man damit irgendwelche Killefitzsachen verwalten möchte, aber wenn es auf Datenkonsistenz auch unter erschwerten Bedingungen ankommt, kann man es vergessen. PostgreSQL kenne ich nicht, weiß auch nicht, welche Ansprüche es erfüllt. Aber wie gesagt, imho ist SQL sowieso total daneben. Nicht wegen der Funktionalität, sondern wegen der Syntax. Wenn schon alles neu gemacht wird, dann bitte eine Datenbanksprache mit vernünftiger Syntax. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Moin,
* Bernd Brodesser
* Thorsten Haude schrieb am 09.Dez.2002:
Für Linux gibt es PostgreSQL, das ist wohl das beste System, das es zur Zeit für diesen Zweck gibt.
Für welchen Zweck? Entweder ich nehme ein DBMS, daß ruhigen Gewissens auch meine Bank auf ihren Host laufen läßt, um mein Geld zu verwalten, oder ich lasse es ganz bleiben.
Deine Ansprüche sind hoch. Ich nehme an, Du setzt auch daheim auf mehrfach redundante SANs, load-balancing Cluster und die entsprechende Überwachungssoftware?
MySQL ist ja gut und schön, wenn man damit irgendwelche Killefitzsachen verwalten möchte, aber wenn es auf Datenkonsistenz auch unter erschwerten Bedingungen ankommt, kann man es vergessen.
Das habe ich auch nicht erwähnt.
PostgreSQL kenne ich nicht, weiß auch nicht, welche Ansprüche es erfüllt. Aber wie gesagt, imho ist SQL sowieso total daneben. Nicht wegen der Funktionalität, sondern wegen der Syntax. Wenn schon alles neu gemacht wird, dann bitte eine Datenbanksprache mit vernünftiger Syntax.
Man wird kaum mit SQL auf seine Daten zugreifen, ich verstehe auch nicht, wie Du auf diese Idee kommst. Auch für SQL-basierte Datenbanken gibt es graphische Frontends, für diesen Zweck wird man sich nochmal mehr Gedanken machen müssen.
ACK = ACKnowledge = Zustimmung
Ich versteh's immer noch nicht. Bei TCP bedeutet ACK nur, daß eine Nachricht angekommen ist. Thorsten -- The existing IP companies have nothing to offer in the new world, and no hope of adopting. Therefore they must fight to the death to maintain the old one. - crucini
* Thorsten Haude schrieb am 09.Dez.2002:
* Bernd Brodesser
[02-12-09 17:15]: * Thorsten Haude schrieb am 09.Dez.2002:
Für welchen Zweck? Entweder ich nehme ein DBMS, daß ruhigen Gewissens auch meine Bank auf ihren Host laufen läßt, um mein Geld zu verwalten, oder ich lasse es ganz bleiben.
Deine Ansprüche sind hoch. Ich nehme an, Du setzt auch daheim auf mehrfach redundante SANs, load-balancing Cluster und die entsprechende Überwachungssoftware?
Es geht nicht um meine Ansprüche. Es geht um das Dateisystem. Es soll doch wohl universell einsetzbar sein, oder etwa nicht? Wenn es universell einsetzbar sein soll, dann muß es auch die Bank auf ihren Host einsetzen können.
PostgreSQL kenne ich nicht, weiß auch nicht, welche Ansprüche es erfüllt. Aber wie gesagt, imho ist SQL sowieso total daneben. Nicht wegen der Funktionalität, sondern wegen der Syntax. Wenn schon alles neu gemacht wird, dann bitte eine Datenbanksprache mit vernünftiger Syntax.
Man wird kaum mit SQL auf seine Daten zugreifen, ich verstehe auch nicht, wie Du auf diese Idee kommst. Auch für SQL-basierte Datenbanken gibt es graphische Frontends, für diesen Zweck wird man sich nochmal mehr Gedanken machen müssen.
Es geht nicht um Frontend, sondern um die Art und Weise, wie der Kernel an seine Daten kommt. Das will auch programmiert sein. Da ist eine vernünftige Syntax auch ganz gut. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Moin,
* Bernd Brodesser
* Thorsten Haude schrieb am 09.Dez.2002:
* Bernd Brodesser
[02-12-09 17:15]: * Thorsten Haude schrieb am 09.Dez.2002:
Für welchen Zweck? Entweder ich nehme ein DBMS, daß ruhigen Gewissens auch meine Bank auf ihren Host laufen läßt, um mein Geld zu verwalten, oder ich lasse es ganz bleiben.
Deine Ansprüche sind hoch. Ich nehme an, Du setzt auch daheim auf mehrfach redundante SANs, load-balancing Cluster und die entsprechende Überwachungssoftware?
Es geht nicht um meine Ansprüche. Es geht um das Dateisystem. Es soll doch wohl universell einsetzbar sein, oder etwa nicht?
Nicht zwingend, die Ansprüche sind eben verschieden. SANs sind letztlich auch universell einsetzbar.
Wenn es universell einsetzbar sein soll, dann muß es auch die Bank auf ihren Host einsetzen können.
Keine Bank würde ihre Daten einem nackten ext3 anvertrauen, und das ist auch gut so.
PostgreSQL kenne ich nicht, weiß auch nicht, welche Ansprüche es erfüllt. Aber wie gesagt, imho ist SQL sowieso total daneben. Nicht wegen der Funktionalität, sondern wegen der Syntax. Wenn schon alles neu gemacht wird, dann bitte eine Datenbanksprache mit vernünftiger Syntax.
Man wird kaum mit SQL auf seine Daten zugreifen, ich verstehe auch nicht, wie Du auf diese Idee kommst. Auch für SQL-basierte Datenbanken gibt es graphische Frontends, für diesen Zweck wird man sich nochmal mehr Gedanken machen müssen.
Es geht nicht um Frontend, sondern um die Art und Weise, wie der Kernel an seine Daten kommt. Das will auch programmiert sein. Da ist eine vernünftige Syntax auch ganz gut.
Auch das muß nicht mit SQL passieren. Es gibt immer noch Datanbanken, die ohne auskommen (allerdings fällt mir gerade nur eine ein), und zB. Postgres unterstützt das erst, seit es PostgreSQL heißt. Übrigens wirst Du keine Sprache finden, an der niemand etwas auszusetzen hat. Thorsten -- If I have seen further, it is by standing on the shoulders of giants. - Sir Isaac Newton
On Mon, 09 Dez 2002 at 13:40 (+0100), Thorsten Haude wrote:
* Bernd Brodesser
[02-12-09 12:20]: Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?
Irgendwie schon, die Datenbankengine heißt Jet.
Ähem - Jet ist AFAIK die Engine von MS-Access, MS-SQL-Server ist schon ein *richtiges* DBMS (und seitdem es row-level-locking kann, auch für OLTP = *Online Transaction Processing* zu gebrauchen). Nehmt es mir nicht übel, aber irgendwie habe ich den Eindruck, dass Ihr beide nicht so richtig wisst, worüber Ihr da schreibt. Den MS-SQL-Server jedenfalls könnt Ihr offensichtlich nicht einschätzen. Das ist mitnichten ein Frontend - es gibt (IIRC jetzt als MMC-Snapin) nur ein paar Admin-Frontends dazu. Wenn man will, kann man MS-Access als Oberfläche verwenden (wie für jede ODBC-DB auch), wenn man nur MS-Client-Anwendungen braucht.
Natürlich geht es um das RDBMS und das sollte doch professionell sein, die höchsten Anforderungen erfüllen. Es hat doch keinen Sinn, wenn man für höhere Ansprüche ein weiteres DBMS auf der Platte bräuchte.
Ich glaube, wir haben hier ein Mißverständnis. Ich spreche hier von Windows, Du offensichtlich nicht.
Für Linux gibt es PostgreSQL, das ist wohl das beste System, das es zur Zeit für diesen Zweck gibt.
Für welchen Zweck? Wie sieht es denn mit Interbase, DB/2, Oracle, Adabas, Sap-DB aus? Kannst Du da mal eine kleine Analyse zu geben? Wieveile von diesen DBMS kennst Du denn? Jan
Moin,
* Jan Trippler
On Mon, 09 Dez 2002 at 13:40 (+0100), Thorsten Haude wrote:
* Bernd Brodesser
[02-12-09 12:20]: Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?
Irgendwie schon, die Datenbankengine heißt Jet.
Ähem - Jet ist AFAIK die Engine von MS-Access, MS-SQL-Server ist schon ein *richtiges* DBMS (und seitdem es row-level-locking kann, auch für OLTP = *Online Transaction Processing* zu gebrauchen).
Ach. Na, ich habe gehört, daß Jet eben die Basis für beides ist.
Nehmt es mir nicht übel, aber irgendwie habe ich den Eindruck, dass Ihr beide nicht so richtig wisst, worüber Ihr da schreibt. Den MS-SQL-Server jedenfalls könnt Ihr offensichtlich nicht einschätzen.
Wann habe ich das denn versucht?
Für Linux gibt es PostgreSQL, das ist wohl das beste System, das es zur Zeit für diesen Zweck gibt.
Für welchen Zweck? Wie sieht es denn mit Interbase, DB/2, Oracle, Adabas, Sap-DB aus?
Das habe ich vergessen, ich meinte natürlich Freie Systeme.
Kannst Du da mal eine kleine Analyse zu geben? Wieveile von diesen DBMS kennst Du denn?
Das überlasse ich lieber Leuten, die schlauer sind als ich, wie Du etwa. Thorsten -- If people could put rainbows in zoos, they'd do it. - Hobbes
On Mon, 09 Dez 2002 at 23:03 (+0100), Thorsten Haude wrote:
* Jan Trippler
[02-12-09 21:09]: [...] Für welchen Zweck? Wie sieht es denn mit Interbase, DB/2, Oracle, Adabas, Sap-DB aus?
Das habe ich vergessen, ich meinte natürlich Freie Systeme.
Und - was hälst Du dann z. B. von Interbase?
Kannst Du da mal eine kleine Analyse zu geben? Wieveile von diesen DBMS kennst Du denn?
Das überlasse ich lieber Leuten, die schlauer sind als ich, wie Du etwa.
Wir sind heute wieder lustig, ne? Ich wollte eigentlich darauf hinweisen, dass man mit Aussagen wie _das beste für diesen Zweck_ etwas vorsichtig sein sollte, wenn man nur eins kennt. _Ich_ würde eine derartige Aussage nicht machen, obwohl ich mit einigen der aufgezählten DBMS mehr oder weniger lange gearbeitet habe. Die Eignung eines so komplexen Systems wie es eine DB-Engine darstellt für eine bestimmte Aufgabe ist nicht mal so schnell mit der *Pi-mal-Fensterkreuz*-Schätzung festzustellen. Jan
Moin,
* Jan Trippler
On Mon, 09 Dez 2002 at 23:03 (+0100), Thorsten Haude wrote:
* Jan Trippler
[02-12-09 21:09]: Kannst Du da mal eine kleine Analyse zu geben? Wieveile von diesen DBMS kennst Du denn?
Das überlasse ich lieber Leuten, die schlauer sind als ich, wie Du etwa.
Wir sind heute wieder lustig, ne?
Ich habe nur keinen Bock auf Leute, die sich mit falschen Behauptungen in eine Diskussion einmischen, deren Charakter die vollständig falsch einschätzen. Thorsten -- Auch Hunger ist Krieg. - Willy Brandt
* Jan Trippler schrieb am 09.Dez.2002:
On Mon, 09 Dez 2002 at 13:40 (+0100), Thorsten Haude wrote:
* Bernd Brodesser
[02-12-09 12:20]:
Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?
[...]
Nehmt es mir nicht übel, aber irgendwie habe ich den Eindruck, dass Ihr beide nicht so richtig wisst, worüber Ihr da schreibt. Den MS-SQL-Server jedenfalls könnt Ihr offensichtlich nicht einschätzen.
Habe ich irgendwie klar und deutlich geschrieben. MS-SQL hört sich aber nicht so an, als erfülle es die höchsten Ansprüche, die man an einer DB stellen kann. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
On Die, 10 Dez 2002 at 03:11 (+0100), Bernd Brodesser wrote:
* Jan Trippler schrieb am 09.Dez.2002:
On Mon, 09 Dez 2002 at 13:40 (+0100), Thorsten Haude wrote:
* Bernd Brodesser
[02-12-09 12:20]: Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?
[...]
Nehmt es mir nicht übel, aber irgendwie habe ich den Eindruck, dass Ihr beide nicht so richtig wisst, worüber Ihr da schreibt. Den MS-SQL-Server jedenfalls könnt Ihr offensichtlich nicht einschätzen.
Habe ich irgendwie klar und deutlich geschrieben.
MS-SQL hört sich aber nicht so an, als erfülle es die höchsten Ansprüche, die man an einer DB stellen kann.
Das muss ich mal einem Kunden erzählen: *Produkt xyz hört sich nicht so an, als ob es auf Ihre Anforderungen passt*. Jan
Hallo, On Mon, 09 Dec 2002, Thorsten Haude wrote:
* Bernd Brodesser
[02-12-09 12:20]: Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?
Irgendwie schon, die Datenbankengine heißt Jet.
*die passende sig dazu raussuch* -dnh, 'nuff said -- [about the "M$ Jet Engine"] But it's a very appropriate name, in that a jet engine is something that both sucks and blows. -- Paul Tomblin ... and if stuff gets inside, it either gets utterly mashed or causes the engine to disintegrate. -- Rik Steenwinkel
Am Montag, 9. Dezember 2002 10:59 schrieb Thorsten Haude:
Sicherlich wird es MS-SQL sein, was denn sonst?
Ich fänds viel cooler, wenn MS ne Oracle-DB für die Verwaltung der Dateien im nächsten Windows nehmen würde ;-) Aber ich denke der primäre Grund für eine solche Umstellung bei MS dürfte Paladium sein, immerhin wird es reichlich kompliziert das ganze Rechtezeugs zu verwalten, wenn die Daten im Filesystem einfach so rumligen. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Montag, 9. Dezember 2002 13:38 schrieb Manfred Tremmel:
Am Montag, 9. Dezember 2002 10:59 schrieb Thorsten Haude:
Sicherlich wird es MS-SQL sein, was denn sonst?
Ich fänds viel cooler, wenn MS ne Oracle-DB für die Verwaltung der Dateien im nächsten Windows nehmen würde ;-) Aber ich denke der primäre Grund für eine solche Umstellung bei MS dürfte Paladium sein, immerhin wird es reichlich kompliziert das ganze Rechtezeugs zu verwalten, wenn die Daten im Filesystem einfach so rumligen.
Warum denkt ihr eigentlich so kompliziert? Wenn es von M$ kommt, werden sie dem alten Kind nur wieder einen neuen Namen gegeben haben. Was ist denn z.B. eine FAT? Letztendlich doch eine Datenbank, in der hinterlegt wird, auf welche physischen Plattenfragmente die Datei hingekleckert wurde. Auch bei Novell ist die NDS letztendlich eine Datenbank. Das physische Speichern hat doch ohnehin bei keinem Dateisystem direkt etwas mit der Dateisystemstruktur zu tun, sondern folgt den Notwendigkeiten des Mediums. Und auf LW-Buchstaben kann man zumindest seit W2k auch verzichten, so man will. Was soll daran also so wahnsinnig neu sein? Es wird kaum eine SQL-Datenbank sein, sondern eher eine hierarchische Struktur wie jetzt auch. Evtl. (wahrscheinlich sogar) ahnlich der NDS von Novell oder LDAP - ist ja alles letztendlich eine Familie. Aber M$ kann es ja trotzdem noch mal neu erfinden und dann als eigenes verkaufen ;-) -- Gruß MaxX
Hallo Matthias, Matthias Houdek schrieb
gegeben haben. Was ist denn z.B. eine FAT? Letztendlich doch eine Datenbank,
Na? Was ist denn nun eine FAT? ;-) Eine FAT ist definitiv keine Datenbank! Es ist eine schlichte (und ziemlich dumme) Liste, bei der zu jedem Dateinamen der Erste Speicherpunkt auf der Festplatte liegt. Mehr nicht. Die ist nicht einmal auf normalem Wege intern sortierbar (Seit Windows weiß das aber keiner mehr ;-) ). Keine Verknüpfungen mit anderen Dateien (das kann auch nicht einmal NTFS), Keine redundanzfreie Sammlung von Daten aus unterschiedlichen Quellen, Keine Indizierung der Inhalte....
Was soll daran also so wahnsinnig neu sein?
Die Anforderungen an professionelle Serversysteme. Beispiel: Du erstellt einen Bericht über die Umsätze Deines Unternehmens und trägt die Werte Deiner Niederlassung ein. Sodann leitest Du die Datei weiter. Dein Kollege in hält die Datei nicht für vollständig und erweitert diese. ZACK! er hat vergessen der Datei einen neuen Namen zu geben, Deine Version ist verschütt. Oder? Hast Du eine Kopie auf Deinem Rechner? Ja, hast Du. Jetzt gibt es zwei Möglichkeiten: Dein Kollege hat alles richtig gemacht, die neue Datei ist O.K. Dann hast Du wieder eine Karteileiche auf Deinem Rechner, die Du wahrscheinlich in zwei Monaten vergessen hast und desshalb vorsichtshalber nicht löscht, weil Dir gerade nicht einfällt, was drin steht. Andere Möglichkeit: Dein Kollege hat versehentlich etwas gelöscht, was besser drin geblieben wäre. Gratulation. Du ersetzt aus Deiner Kopie den fehlenden Teil. Jetzt hat aber Dein Kollege die Karteileiche. Und stell Dir jetzt noch vor, alle drei Versionen geistern in der Firma umher! Da hilft die Datenbank. Du und Dein Kollege braucht dann keine Kopie mehr, das Filesystem "erinnert" sich an die Vorgängerversionen einer einzigen Datei. Noch drei Jahre später kommt Dein Chef und fragt Dich nach einem Dokument mit einem bestimmten Inhalt, weiß aber nicht mehr, daß dies Dein Umsatzbericht war. Und jetzt? Würdest Du jetzt eine Volltextsuche über das Unternehmensnetz starten, brauchte dies nicht nur gewaltige Rechenleistung, es kämen auch auf einmal mehrere (redundante) Dokumente aus verschiedenen Quellen zu Tage (einige haben spätere Berichte teilweise auch noch bei Dir abgeschrieben), die Du nur noch durch lesen qualifizieren kannst. Bei einem Datenbank-Filesystem hättest Du in kürzester Zeit zwar auch alle verschiedenen Ausführungen, aber Du wüstest auch, welches die endgültigen Versionen der Dokumente sind. Der Aufwand das richtige Dokument zu finden ist dann wahrscheinlich um Klassen niedriger. Soweit zum Funktionsumfang eines EDM/PDM Systems. Diese Funktionalität auf Betriebssystemebene herunterzubringen ist IMHO nur eine logische (und sehr umsatzträchtige) Entwicklung. Und M$ hatte immer schon ein Gespür dafür, wie man anderen das Wasser abgräbt. Zudem gibt es schon seit Win3.11 die Möglichkeit einer Datei Zusatzinformationen zu geben. Warscheinlich hat sie kaum jemand genutzt, jetzt wird dies zum Schlüssel. so long... Achim
* Achim Luft schrieb am 09.Dez.2002:
Eine FAT ist definitiv keine Datenbank! Es ist eine schlichte (und ziemlich dumme) Liste, bei der zu jedem Dateinamen der Erste Speicherpunkt auf der Festplatte liegt. Mehr nicht. Die ist nicht einmal auf normalem Wege intern sortierbar (Seit Windows weiß das aber keiner mehr ;-) ).
Du schreibst, wo der erste Speicherpunkt auf der Festplatte liegt. Der nächste Speicherpunkt steht am Ende des ersten Blocks. Ist das richtig? Wenn dem so ist, dann ist FAT maximal daneben. Das hieße, wenn man irgendwo auf eine große Datei zugreifen will, dann muß man sich immer wieder durchhangeln? Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
Hallo Bernd, Bernd Brodesser schrieb:
Du schreibst, wo der erste Speicherpunkt auf der Festplatte liegt. Der nächste Speicherpunkt steht am Ende des ersten Blocks. Ist das richtig? Wenn dem so ist, dann ist FAT maximal daneben. Das hieße, wenn man irgendwo auf eine große Datei zugreifen will, dann muß man sich immer wieder durchhangeln?
völlig korrekt. Es ist eine simple verkettete Liste aus der Urknallphase der Computertechnik, also nicht einmal Steinzeit ;-) . so long ... Achim
* On Tue, 10 Dec 2002 at 18:09 +0100, Achim Luft wrote:
Bernd Brodesser schrieb:
Du schreibst, wo der erste Speicherpunkt auf der Festplatte liegt. Der nächste Speicherpunkt steht am Ende des ersten Blocks. Ist das
Nein, steht er nicht. Die FAT ist (wie schon der Name sagt) eine Tabelle, die am Anfang der Platte steht, in der je Block die Nummer des Folgeblocks vermerkt ist, oder alternativ ein reservierter Wert, der angibt, daß der File mit diesem Block endet oder der Block defekt/resreviert/$whatever ist. Aufgrund der Brisanz der enthaltenen Daten wurde FAT meist in zweifacher Ausfertigung abgelegt. Auf die FAT(s) folgte dann das root-Verzeichnis, und dann die eigentlichen Datenblöcke.
richtig? Wenn dem so ist, dann ist FAT maximal daneben. Das hieße, wenn man irgendwo auf eine große Datei zugreifen will, dann muß man sich immer wieder durchhangeln?
Durchhangeln, ja. Aber wie sollte man sonst unbekannte Mengen von Daten speichern, ohne sich wo durchhangeln zu müssen? ext2 ist in dem Punkt sicher nicht viel besser - um genauer zu sein, um ein Stück aufwendiger.
völlig korrekt. Es ist eine simple verkettete Liste aus der Urknallphase der Computertechnik, also nicht einmal Steinzeit ;-) .
Und trotzdem sind verkettete Listen immer noch verdammt aktuell. -- Adalbert GPG welcome, request public key: mailto:adalbert+key@lopez.at
* Adalbert Michelic schrieb am 10.Dez.2002:
* On Tue, 10 Dec 2002 at 18:09 +0100, Achim Luft wrote:
Bernd Brodesser schrieb:
Du schreibst, wo der erste Speicherpunkt auf der Festplatte liegt. Der nächste Speicherpunkt steht am Ende des ersten Blocks. Ist das
Nein, steht er nicht. Die FAT ist (wie schon der Name sagt) eine Tabelle, die am Anfang der Platte steht, in der je Block die Nummer des Folgeblocks vermerkt ist, oder alternativ ein reservierter Wert, der angibt, daß der File mit diesem Block endet oder der Block defekt/resreviert/$whatever ist.
Aufgrund der Brisanz der enthaltenen Daten wurde FAT meist in zweifacher Ausfertigung abgelegt. Auf die FAT(s) folgte dann das root-Verzeichnis, und dann die eigentlichen Datenblöcke.
richtig? Wenn dem so ist, dann ist FAT maximal daneben. Das hieße, wenn man irgendwo auf eine große Datei zugreifen will, dann muß man sich immer wieder durchhangeln?
Durchhangeln, ja. Aber wie sollte man sonst unbekannte Mengen von Daten speichern, ohne sich wo durchhangeln zu müssen? ext2 ist in dem Punkt sicher nicht viel besser - um genauer zu sein, um ein Stück aufwendiger.
Moment, moment. Wenn ich mit dem Systemaufruf lseek den Zeiger einer Datei auf eine beliebige, aber feste Position verlege, dann wird zuerst nachgerechnet, im wievielten Block sich die Position befindet. Dann wird in der I-Node nachgesehen, wo sich dieser Block befindet. Dafür sind dann evtl. (bei dreifach indirekte Blöcke) noch drei Zugriffe auf indirekt-Blöcke notwendig. Dann hat man aber den Block und dann wird der Block im Hauptspeicher gelesen und auf der entsprechenden Position gesetzt. So bei ext-Dateisysteme. Wenn ich das mit FAT richtig verstanden habe, muß zuerst der erste Block gelesen werden, dann der zweite usw. bis zum, sagen wir mal fünftausendsechshundertdreiundzwanzigsten. Wenn dem so ist, finde ich das nicht optimal.
völlig korrekt. Es ist eine simple verkettete Liste aus der Urknallphase der Computertechnik, also nicht einmal Steinzeit ;-) .
Und trotzdem sind verkettete Listen immer noch verdammt aktuell.
Kommt darauf an, wo. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
* On Tue, 10 Dec 2002 at 21:02 +0100, Bernd Brodesser wrote:
* Adalbert Michelic schrieb am 10.Dez.2002:
* On Tue, 10 Dec 2002 at 18:09 +0100, Achim Luft wrote:
Bernd Brodesser schrieb:
Du schreibst, wo der erste Speicherpunkt auf der Festplatte liegt. Der nächste Speicherpunkt steht am Ende des ersten Blocks. Ist das
Nein, steht er nicht. Die FAT ist (wie schon der Name sagt) eine Tabelle, die am Anfang der Platte steht, in der je Block die Nummer des Folgeblocks vermerkt ist, oder alternativ ein reservierter Wert, der angibt, daß der File mit diesem Block endet oder der Block defekt/resreviert/$whatever ist.
Aufgrund der Brisanz der enthaltenen Daten wurde FAT meist in zweifacher Ausfertigung abgelegt. Auf die FAT(s) folgte dann das root-Verzeichnis, und dann die eigentlichen Datenblöcke.
richtig? Wenn dem so ist, dann ist FAT maximal daneben. Das hieße, wenn man irgendwo auf eine große Datei zugreifen will, dann muß man sich immer wieder durchhangeln?
Durchhangeln, ja. Aber wie sollte man sonst unbekannte Mengen von Daten speichern, ohne sich wo durchhangeln zu müssen? ext2 ist in dem Punkt sicher nicht viel besser - um genauer zu sein, um ein Stück aufwendiger.
Moment, moment. Wenn ich mit dem Systemaufruf lseek den Zeiger einer Datei auf eine beliebige, aber feste Position verlege, dann wird zuerst nachgerechnet, im wievielten Block sich die Position befindet. Dann wird in der I-Node nachgesehen, wo sich dieser Block befindet. Dafür sind dann evtl. (bei dreifach indirekte Blöcke) noch drei Zugriffe auf indirekt-Blöcke notwendig. Dann hat man aber den Block und dann wird der Block im Hauptspeicher gelesen und auf der entsprechenden Position gesetzt. So bei ext-Dateisysteme.
Wenn ich das mit FAT richtig verstanden habe, muß zuerst der erste Block gelesen werden, dann der zweite usw. bis zum, sagen wir mal fünftausendsechshundertdreiundzwanzigsten. Wenn dem so ist, finde ich das nicht optimal.
Nein, es muss nicht jeder Block einzeln gelesen werden. Diese Daten werden in der FAT nachgeschlagen. Das sind zwar möglicherweise mehr Zugriffe als bei ext2, jedoch muß nicht jeder Block einzeln gelesen werden. Eine Speicherung der Daten wie z.B. bei ext2 hätte für den Einsatzzweck, für den das ursprünglich entwickelt worden ist, weit zuviel Platz gefressen, bzw. wäre zu aufwendig gewesen. Der Mehraufwand, der durch die Abarbeitung einer verketteten Liste im Gegensatz zum Konzept wie bei ext2 entsteht, ist jedenfalls angesichts der Zeit, die zum Lesen eines Blocks von der Platte gebraucht wird, vernachlässigbar. Auch auf einem extrem langsamen System. -- Adalbert GPG welcome, request public key: mailto:adalbert+key@lopez.at
Am Montag, 9. Dezember 2002 23:36 schrieb Achim Luft:
Hallo Matthias,
Matthias Houdek schrieb
gegeben haben. Was ist denn z.B. eine FAT? Letztendlich doch eine Datenbank,
Na? Was ist denn nun eine FAT? ;-)
Eine FAT ist definitiv keine Datenbank!
Gut, jetzt wäre zu definieren, was eine Datenbank ist *g*.
Es ist eine schlichte (und ziemlich dumme) Liste, bei der zu jedem Dateinamen der Erste Speicherpunkt auf der Festplatte liegt. Mehr nicht. Die ist nicht einmal auf normalem Wege intern sortierbar (Seit Windows weiß das aber keiner mehr ;-) ).
Oups. Naja, ich hab mich damit seit CP/M-Zeiten nicht mehr bewusst auseinandergesetzt, weil ich es nicht mehr brauchte. Damals wurden dort noch alle Sektoren, in denen die Datei liegt, dort eingetragen (iirc). Aber du hast Recht, wäre sonst wohl auch etwas unhandlich so.
Keine Verknüpfungen mit anderen Dateien (das kann auch nicht einmal NTFS), Keine redundanzfreie Sammlung von Daten aus unterschiedlichen Quellen, Keine Indizierung der Inhalte....
Muss das eine Datenbank können? Ist das Voraussetzung, um von einer Datenbank reden zu können? Eine Datenbank muss Entitäten mit dazugehörigen Eigenschaften strukturiert aufnehmen können. Das kann eine FAT.
Was soll daran also so wahnsinnig neu sein?
Die Anforderungen an professionelle Serversysteme.
Wenn denen damit gerecht würde. Das ist aber noch _die_ Frage ;-)
Beispiel:
Du erstellt einen Bericht über die Umsätze Deines Unternehmens und trägt die Werte Deiner Niederlassung ein. Sodann leitest Du die Datei weiter. Dein Kollege in hält die Datei nicht für vollständig und erweitert diese. ZACK! er hat vergessen der Datei einen neuen Namen zu geben, Deine Version ist verschütt. Oder? Hast Du eine Kopie auf Deinem Rechner? Ja, hast Du. Jetzt gibt es zwei Möglichkeiten: Dein Kollege hat alles richtig gemacht, die neue Datei ist O.K. Dann hast Du wieder eine Karteileiche auf Deinem Rechner, die Du wahrscheinlich in zwei Monaten vergessen hast und desshalb vorsichtshalber nicht löscht, weil Dir gerade nicht einfällt, was drin steht.
Na, ob das die M$-Datei-Datenbank kann?
Andere Möglichkeit: Dein Kollege hat versehentlich etwas gelöscht, was besser drin geblieben wäre. Gratulation. Du ersetzt aus Deiner Kopie den fehlenden Teil. Jetzt hat aber Dein Kollege die Karteileiche. Und stell Dir jetzt noch vor, alle drei Versionen geistern in der Firma umher!
Da hilft die Datenbank. Du und Dein Kollege braucht dann keine Kopie mehr, das Filesystem "erinnert" sich an die Vorgängerversionen einer einzigen Datei. Noch drei Jahre später kommt Dein Chef und fragt Dich nach einem Dokument mit einem bestimmten Inhalt, weiß aber nicht mehr, daß dies Dein Umsatzbericht war. Und jetzt? Würdest Du jetzt eine Volltextsuche über das Unternehmensnetz starten, brauchte dies nicht nur gewaltige Rechenleistung, es kämen auch auf einmal mehrere (redundante) Dokumente aus verschiedenen Quellen zu Tage (einige haben spätere Berichte teilweise auch noch bei Dir abgeschrieben), die Du nur noch durch lesen qualifizieren kannst. Bei einem Datenbank-Filesystem hättest Du in kürzester Zeit zwar auch alle verschiedenen Ausführungen, aber Du wüstest auch, welches die endgültigen Versionen der Dokumente sind. Der Aufwand das richtige Dokument zu finden ist dann wahrscheinlich um Klassen niedriger.
Richtig. Wäre schön, wenn das so wäre. Aber es soll doch vom Microsoft kommen ...?
Soweit zum Funktionsumfang eines EDM/PDM Systems. Diese Funktionalität auf Betriebssystemebene herunterzubringen ist IMHO nur eine logische (und sehr umsatzträchtige) Entwicklung. Und M$ hatte immer schon ein Gespür dafür, wie man anderen das Wasser abgräbt. Zudem gibt es schon seit Win3.11 die Möglichkeit einer Datei Zusatzinformationen zu geben. Warscheinlich hat sie kaum jemand genutzt, jetzt wird dies zum Schlüssel.
Systeme, vorhandene Dateien nach anderen Kriterien als (ausschließlich) ihrem Dateinamen (incl. Pfad) zu klassivizieren, gibt es viele. Ich kenne sowas schon aus den 80ern. Und wenn Microsoft so etwas in das Betriebssystem integriert, wird es sicher so ein Zusatzsystem sein, dass dann so mit systemeigenen DLLs wechselseitig verzahnt wird, dass eines ohne das andere einfach nicht mehr laufen wird (vgl. Internet Explorer)*g* -- Gruß MaxX, Quotenossi und Plenker(er) 8-)
Hallo, Matthias Houdek schrieb:
Und wenn Microsoft so etwas in das Betriebssystem integriert, wird es sicher so ein Zusatzsystem sein, dass dann so mit systemeigenen DLLs wechselseitig verzahnt wird, dass eines ohne das andere einfach nicht mehr laufen wird (vgl. Internet Explorer)*g*
Ich stimme Dir da nur bedingt zu, schliesslich hat Microsoft immer auch Software geschaffen, die in irgendeinem OS scheinbar funktioniert, nach einigen Wochen vielleicht auch wieder nicht, oder auch mal dieses System kann nur... , oder einfach mal ein erfrischendes und alles erklärendes Garnichts . Wohlwissend hat man dann einen sauteuren, zusätzlichen Server geschaffen, der dann endlich auch das alles richtig kann, was die Workstation auch schon können sollte. So wirds sicher auch werden, da brauchen wir uns keinen Illusionen hingeben. Aber ich denke auch, daß die Richtung EDM stimmt. Aber genauso denke ich, daß Linux sich langfristig nicht an M$ klammern muß. Die Marktposition ist für eigene Wege auf dem Server sicher schon vorhanden. Über so etwas würde ich mich jedenfalls wahnsinnig freuen. Denn wenn Redmond eine Wartungsoberfläche für ein Mini-EDM schaffen müßte, kann man auf dem Server alles und auf der Workstation entschieden zu wenig oder die entscheidenden Klicks liegen in der 250. Unterebene eines Menüs einer Textverarbeitung. Eine Trennung von Sytemebene und EDM-Funktionalität halte ich durchaus für sinnvoll, ist sie doch um Klassen flexibler und transparenter. Aber diese Funktionaltät gehört IMHO eben auch nicht auf eine Workstion, sondern auf einen Server. Bei meinen CAD-Systemen führt alleine schon die Indexerstellung nicht nur oft genug zum Tode sondern auch zum Däumchen drehen. Deshalb ist sie auf meinen Rechnern deaktiviert. so long ... Achim
Am Montag, 9. Dezember 2002 23:36 schrieb Achim Luft:
Hallo Matthias,
Matthias Houdek schrieb
gegeben haben. Was ist denn z.B. eine FAT? Letztendlich doch eine Datenbank,
Na? Was ist denn nun eine FAT? ;-)
Eine FAT ist definitiv keine Datenbank! Es ist eine schlichte (und ziemlich dumme) Liste, bei der zu jedem Dateinamen der Erste Speicherpunkt auf der Festplatte liegt. Mehr nicht. Die ist nicht einmal auf normalem Wege intern sortierbar (Seit Windows weiß das aber keiner mehr ;-) ).
Keine Verknüpfungen mit anderen Dateien (das kann auch nicht einmal NTFS), Keine redundanzfreie Sammlung von Daten aus unterschiedlichen Quellen, Keine Indizierung der Inhalte....
Was soll daran also so wahnsinnig neu sein?
Die Anforderungen an professionelle Serversysteme.
Sorry, da kann ich Dir nicht so recht folgen ...
Beispiel:
Du erstellt einen Bericht über die Umsätze Deines Unternehmens und trägt die Werte Deiner Niederlassung ein. Sodann leitest Du die Datei weiter. Dein Kollege in hält die Datei nicht für vollständig und erweitert diese. ZACK! er hat vergessen der Datei einen neuen Namen zu geben, Deine Version ist verschütt. Oder? Hast Du eine Kopie auf Deinem Rechner? Ja, hast Du. Jetzt gibt es zwei Möglichkeiten: Dein Kollege hat alles richtig gemacht, die neue Datei ist O.K. Dann hast Du wieder eine Karteileiche auf Deinem Rechner, die Du wahrscheinlich in zwei Monaten vergessen hast und desshalb vorsichtshalber nicht löscht, weil Dir gerade nicht einfällt, was drin steht.
Dazu kann man einer/der Datei eine _aussagekräftigen_ Namen geben ... wir sind hier nicht mehr bei DOS!!!
[ .... ]
Soweit zum Funktionsumfang eines EDM/PDM Systems. Diese Funktionalität
Den hast Du ziemlich gut beschrieben, da (nur da) gehört sowas auch hin!!! Es ist aber _kein_ FileSystem!!!
auf Betriebssystemebene herunterzubringen ist IMHO nur eine logische (und sehr umsatzträchtige) Entwicklung. Und M$ hatte immer schon ein Gespür dafür, wie man anderen das Wasser abgräbt. Zudem gibt es schon seit Win3.11 die Möglichkeit einer Datei Zusatzinformationen zu geben. Warscheinlich hat sie kaum jemand genutzt, jetzt wird dies zum Schlüssel.
Echt toll, nur was sollen z.B. meine Webserver damit ??? Solche Systeme leben insbes. davon, daß die Daten entspr. indiziert werden, erklär das mal dem DAU! - Der bekommt es doch heute schon nicht richtig hin seinen (digitalen) Urlaubsfotos richtige (Datei-)Namen zu geben. Alles was das kostet sind Unheimlich Rechenpower und Speicher ... 1. DBMS sind nur relativ schnell, wenn die relevanten Daten/Indizes im RAM liegen. 2. Vergleich mal: a) cat ~/ich/Brief-an-Oma.txt b) SELECT * FROM "Dokumente" where "Text" ~* 'Hallo Oma'; 3. Ausfallsicherheit, wenn die Platte eine Macke hat oder der Strom weg ist, macht das einem normalen (guten) FS relativ wenig Probleme. Eine DB hat da wesentlich mehr Probleme ... happy backuping ... Das bringt endlich die Möglichkeiten, auf die Intel und Co. so lange gewartet haben. Jetzt können Sie jedem "Normal-DAU" schlüssig erklären, das er (mindestens) einen P7 mit 12,8 GHz, 4 TByte RAM und eine 12,7 PByte HD (RAID) braucht. Die größere Herausforderung ist herauszufiltern, was nach /dev/null verschoben wird, als immer mehr sinnlosen Müll zu archivieren. Mal ehrlich, alles dorthin, wo es hingehört! Frohes Fest und Tschö Mirko -- +--[ Mirko Richter (RHCE) ]------------------------+ | Networks & Communicationsystems | | Mirko Richter | | Ernst-Thaelmann-Str. 5, D-06774 Soellichau | | E-MAIL: m.richter@ngi.de | | Tel. +49/(0)34243/3369-50 \\\\ | | Fax. +49/(0)34243/3369-28 (O O) | +-----------------------------------oOOo-(_)-oOOo--+
* Mirko Richter schrieb am 10.Dez.2002:
3. Ausfallsicherheit, wenn die Platte eine Macke hat oder der Strom weg ist, macht das einem normalen (guten) FS relativ wenig Probleme. Eine DB hat da wesentlich mehr Probleme ... happy backuping ...
was? Nein, eine vernünftige DB hat keine Probleme, wenn der Strom ausfällt. Sowas ist doch Aufgabe einer DB, auch unter schwierigen Bedingungen Konsistent zu sein. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Am Dienstag, 10. Dezember 2002 08:56 schrieb Bernd Brodesser:
* Mirko Richter schrieb am 10.Dez.2002:
3. Ausfallsicherheit, wenn die Platte eine Macke hat oder der Strom weg ist, macht das einem normalen (guten) FS relativ wenig Probleme. Eine DB hat da wesentlich mehr Probleme ... happy backuping ...
was? Nein, eine vernünftige DB hat keine Probleme, wenn der Strom ausfällt. Sowas ist doch Aufgabe einer DB, auch unter schwierigen Bedingungen Konsistent zu sein.
Ja das ist so schon richtig, nur wenn der Datenbank der Boden unter den Füßen weggerissen wird, dann hat man mehr Probleme als bei einem normalen FS. Ich hab's schon mal durchgemacht, ist so ca. 2 Jahre her. Das war ne InterBase, da gab es einen Stromausfall, die UPS ist hochgegangen ;) , dadurch wurde div. Plattenfehler verursacht. So ziemlich alle Dateien ließen sich wieder herstellen, nur die Datenbank ließ sich nicht mehr zum Leben erwecken. Alle Versuche scheiterten. Also Backups einspielen, hat bloß 10 Stunden gedauert .... Im Highendbereich macht sowas ja nichts, da werden genügend Maßnahmen getroffen, damit das nicht passiert. - Redundante Sromversorgung - redundante Platten etc. Diesen Aufwand kann/will Otto Normalo einfach nicht betreiben, wo es auf wirkliche Verfügbarkeit ankommt ist auch das Geld dafür da. Was ich meinte, war die Relation zw. DBMS und Normalrechner, weil hier der eine oder andere von diesem System so schwärmten. Bei einer DB kommt es schnell mal zum Supergau - sprich alles wech - wenn kleine Fehler am Speichermedium auftreten. Bei einem normalen FS ist das wesentlich unproblematischer, egal ob ext2 oder FAT ... . Ich mußte schon genügend Daten von Platten retten - hat auch praktisch immer geklappt ;). Es gab genügend Fälle, wo z.B. die Partitionstabelle hin war und damit praktich die ganze Platte Leer oder ein(ige) Sektor(en) der Platte überschrieben worden sind - ob nun durch Dummheit oder z.B. Virus - betrifft dies im allgemeinen nur einzelne Files, wenn das bei einer DB passiert, hast Du größere Probleme. Eine DB2 oder Oracle zum Speichern von Lieschen Müllers Briefchen an Oma ? Für einen 08/15 Arbeitsplatz-PC ist das der blanke OVERKILL! Ich sag immer: "Alles dort, wo es Sinn macht!" MfG Mirko -- +--[ Mirko Richter (RHCE) ]------------------------+ | Networks & Communicationsystems | | Mirko Richter | | Ernst-Thaelmann-Str. 5, D-06774 Soellichau | | E-MAIL: m.richter@ngi.de | | Tel. +49/(0)34243/3369-50 \\\\ | | Fax. +49/(0)34243/3369-28 (O O) | +-----------------------------------oOOo-(_)-oOOo--+
* Mirko Richter schrieb am 10.Dez.2002:
Am Dienstag, 10. Dezember 2002 08:56 schrieb Bernd Brodesser:
* Mirko Richter schrieb am 10.Dez.2002:
3. Ausfallsicherheit, wenn die Platte eine Macke hat oder der Strom weg ist, macht das einem normalen (guten) FS relativ wenig Probleme. Eine DB hat da wesentlich mehr Probleme ... happy backuping ...
was? Nein, eine vernünftige DB hat keine Probleme, wenn der Strom ausfällt. Sowas ist doch Aufgabe einer DB, auch unter schwierigen Bedingungen Konsistent zu sein.
Ja das ist so schon richtig, nur wenn der Datenbank der Boden unter den Füßen weggerissen wird, dann hat man mehr Probleme als bei einem normalen FS.
Das muß eine DB ab können.
Im Highendbereich macht sowas ja nichts, da werden genügend Maßnahmen getroffen, damit das nicht passiert.
- Redundante Sromversorgung - redundante Platten etc.
Ja, einerseits. Aber auch wenn alles versagt. (Die Stromversorgung kann ja im Rechner selber ausfallen, weil eine Maus sich im Rechner eingenistet hat, oder so) müssen die Daten trotzdem konsistent bleiben.
Diesen Aufwand kann/will Otto Normalo einfach nicht betreiben, wo es auf wirkliche Verfügbarkeit ankommt ist auch das Geld dafür da.
So macht es keinen Sinn. Linux wird auch im Highendbereich verwendet. Es ist doch wohl vollkommen daneben, ein Datenbank-basiertes Dateisystem zu haben, aber für eine vernünftige DB doch wieder eine eigenes System.
Eine DB2 oder Oracle zum Speichern von Lieschen Müllers Briefchen an Oma ?
Zumindest mit Oracle und Linux kostet das AFAIK noch nicht mal was. Erst wenn es komerziell eingesetzt wird, will Oracle Geld. Dann aber richtig. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Hallo, On Mon, 09 Dec 2002, Manfred Tremmel wrote:
Am Montag, 9. Dezember 2002 10:59 schrieb Thorsten Haude:
Sicherlich wird es MS-SQL sein, was denn sonst?
Ich fänds viel cooler, wenn MS ne Oracle-DB für die Verwaltung der Dateien im nächsten Windows nehmen würde ;-) Aber ich denke der primäre Grund für eine solche Umstellung bei MS dürfte Paladium sein, immerhin wird es reichlich kompliziert das ganze Rechtezeugs zu verwalten, wenn die Daten im Filesystem einfach so rumligen.
Ack. *seufz* -dnh -- [Java sei nicht das Gelbe vom Ei] Es ist auch nicht das Weiße vom Ei. Eher das grün-bräunliche eines verschimmelten Gammel-Eis. Java ist die gelbliche Ab- lagerung an Pissoirs. Java ist der Schimmelpilz der IT-Branche. Mag sein, daß es eine Funktion erfüllt, aber sie ist noch nicht gefunden worden. -- fefe
Hallo, IMHO ist eine solche Datenbank als Filesystem sinnvoll. Aber sicher auch nicht generell, die meisten Leute sind froh darüber, zu wissen wo die Daten liegen. In meinem Ing.Büro benutzen wir 3D-CAD-Systeme (Maschinenbau). Wenn wir Baugrupen verwalten, werden die Daten von oftmals mehr als 4000 Dateien analysiert. Sie enthalten neben den Geometriedaten, die hierbei nicht verwendet werden, Daten für die Stücklisten, Verwaltungsdaten und Verknüpfungen. Solche Vorgänge dauern oft über 15 Minuten, bevor wir mit der eigentlichen Arbeit anfangen können (Vergleichbar: Volltextsuche). Bei jeder Aktualisierung gehts wieder von vorn los. Spaß macht das nicht! In sofern wäre es sinnvoll, Daten in einer Datenbank zu speichern. Ein ausgezeichneter Ansatz dazu wäre wahrscheinlich eine Kombination aus Samba & MySql. Dann bräuchte sich auch keiner um das Umstricken der Filesysteme zu kümmern ;-) Aber wie wir alle wissen, möchte M$ ja wohl mehr für die eigene Geldbörse, als anderen nur einen Gefallen tun. Schliesslich haben die ja Oracle, db2, SAP, Baan &Co den Kampf angesagt, indem Sie mal wieder kräftig eingekauft haben. Nur darum geht's IMHO, primitiv-Standards durchsetzen, wo andere mit Top-Technik (nach M$-Vorstellungen) zuviel Geld verdienen. so long Achim
On Mon, 09 Dez 2002 at 09:14 (+0100), Bernd Brodesser wrote: [...]
Abgesehen davon ist SQL eine *kotzwürg* Sprache. Mir hat noch keiner erklären können, warum die Syntax für ein UPDATE so total anders ist als die Syntax für ein INSERT. Und warum z.B AND einmal, wie bei vielen anderen Sprachen, als logisches und, und zum anderen als Aufzähltrenner, wo andere Sprachen ein Komma nehmen, verwendet wird.
[ ] Du hast SQL verstanden. Sorry, aber das ist doch hanebüchener Unsinn, was Du da schreibst! Ein Update soll Feldwerte (also einzelne Spalten) eines oder mehrerer durch eine Bedingung definierter Sätze aktualisieren - ein Insert fügt immer einen kompletten neuen Satz hinzu. SQL arbeitet prinzipiell ergebnismengenorientiert - mit Ausnahme des Insert. Deshalb weicht eben die Insert-Syntax vom Select und Update ab. AND dient genau wie in jeder anderen Sprache auch zum Verknüpfen von Bedingungen (bei SQL eben immer dann, wenn vorher ein WHERE stand) - OR wird übrigens haargenau so behandelt. Immer dann, wenn mehrere Spalten nacheinander aufgezählt werden (Select oder update), dann steht da ein Komma. SQL ist im Gegensatz zu prozeduralen oder objektorientierten Programmiersprachen einfach zu lesen, weil sich die Syntax an die natürliche Sprache anlehnt: select spalte1, spalte2 from tabelle where spalte_x > 100 and spalte_y <> 'Nikolaus'; update tabelle set spalte1 = 'A', spalte2 = 1 where spalte_y like 'Niko%' or spalte_z = '2002-12-24'; insert into tabelle values ('x', 'y', 2); SQL (=Structured Query Language) ist mit dem Ziel designed worden, das _Wie_ vor dem Anwender der Sprache zu verbergen - er soll nur noch definieren müssen, _Was_ er als Ergebnis haben will - und das schafft diese Sprache prima. Wenn ich mir vorstelle, komplexe betriebswirtschaftliche Sachverhalte statt in SQL z. B. in C oder Perl oder PHP mit deren originärem Wortschatz abfragen zu müssen, dann wird mir schlecht. DBMS verbergen die physikalischen Grundlagen der Datenhaltung vor dem Frontend - SQL verbirgt die Art und Weise, wie DBMS die angeforderten Daten beschaffen, vor dem Anwender. [...]
Ich kann mir schon ein Datenbankbasiertes Dateisystem vorstellen. Aber das wird, für den Anfänger mit Sicherheit nicht einfacher, als ein hirachisches.
Doch, wenn es richtig gemacht wird, dann ist es das. Dann muss man nämlich nicht mehr wissen, unter welchem Namen und nach welchen Ordnungskriterien man z. B. ein Angebot für ein neues Archiv vor einem halben Jahr abgelegt hat (Chronologisch? nach Kunden? nach Produkt? nach Preis? nach irgendeinem anderen Kriterium?) und was noch viel interessanter ist - Man kann das lokale Dateisystem ähnlich wie eine gute Suchmaschine verwenden: Das war doch mal was mit Archiv und Angebot - zeige mir mal, was da so auf der Pladde liegt! Ob da nun ein relationales DMBS oder ein objektorientiertes DBMS oder ein ausgewachsenes Dokumentenmanagement- und Retrievalsystem im Hintergrund werkelt, ist erstmal nebensächlich. Fakt ist, dass die Schnittstelle zwischen Mensch und Dateisystem intuitiver zu bedienen sein wird. Da sind auch ausgeklügelte find-grep-sed-awk-Mechanismen bald am Ende, weil sie nur syntaktische Zusammenhänge herstellen können, keine semantischen. Jan
* Jan Trippler schrieb am 09.Dez.2002:
On Mon, 09 Dez 2002 at 09:14 (+0100), Bernd Brodesser wrote:
Abgesehen davon ist SQL eine *kotzwürg* Sprache. Mir hat noch keiner erklären können, warum die Syntax für ein UPDATE so total anders ist als die Syntax für ein INSERT. Und warum z.B AND einmal, wie bei vielen anderen Sprachen, als logisches und, und zum anderen als Aufzähltrenner, wo andere Sprachen ein Komma nehmen, verwendet wird.
[ ] Du hast SQL verstanden.
Sorry, aber das ist doch hanebüchener Unsinn, was Du da schreibst! Ein Update soll Feldwerte (also einzelne Spalten) eines oder mehrerer durch eine Bedingung definierter Sätze aktualisieren - ein Insert fügt immer einen kompletten neuen Satz hinzu. SQL arbeitet prinzipiell ergebnismengenorientiert - mit Ausnahme des Insert.
Ja, und?
Deshalb weicht eben die Insert-Syntax vom Select und Update ab.
Es weicht aber weit mehr ab, als es müßte.
AND dient genau wie in jeder anderen Sprache auch zum Verknüpfen von Bedingungen (bei SQL eben immer dann, wenn vorher ein WHERE stand) - OR wird übrigens haargenau so behandelt. Immer dann, wenn mehrere Spalten nacheinander aufgezählt werden (Select oder update), dann steht da ein Komma.
Stimmt schon. Was ich meinte [1] ist das AND bei BETWEEN. Da rollen sich bei mir die Zähennägel auf. BETWEEN 15 AND 23
SQL ist im Gegensatz zu prozeduralen oder objektorientierten Programmiersprachen einfach zu lesen, weil sich die Syntax an die natürliche Sprache anlehnt:
Und genau das ist es. Natürliche Sprachen sind nicht logisch. Mag ja leichter zu lesen sein, aber nicht leichter zu schreiben.
select spalte1, spalte2 from tabelle where spalte_x > 100 and spalte_y <> 'Nikolaus'; update tabelle set spalte1 = 'A', spalte2 = 1 where spalte_y like 'Niko%' or spalte_z = '2002-12-24'; insert into tabelle values ('x', 'y', 2);
Was soll das into? Kann nach einem insert auch was anderes kommen? Bei einem update werden Spalten und Werte direkt zugeordnet, bei einem insert werden zuerst die Spaltennamen aufgezählt, dann die dazugehörige Werte.
SQL (=Structured Query Language) ist mit dem Ziel designed worden, das _Wie_ vor dem Anwender der Sprache zu verbergen - er soll nur noch definieren müssen, _Was_ er als Ergebnis haben will - und das schafft diese Sprache prima.
Nein, ich muß mich an eine enge Syntax halten. In einer natürlichen Sprache bin ich viel freier. Wenn ich mich schon an eine enge Syntax halten muß, dann habe ich viel lieber was logisch aufgebautes, auch wenn es von der natürlich gesprochene Sprache abweicht. Ich kann mir vorstellen, daß es für jemand, der nicht Englisch als Muttersprach hat, und auch keine Sprache, die dem Englischen sehr ähnlich ist, was das Deutsch nun mal ist, seine Probleme hat.
Wenn ich mir vorstelle, komplexe betriebswirtschaftliche Sachverhalte statt in SQL z. B. in C oder Perl oder PHP mit deren originärem Wortschatz abfragen zu müssen, dann wird mir schlecht. DBMS verbergen die physikalischen Grundlagen der Datenhaltung vor dem Frontend - SQL verbirgt die Art und Weise, wie DBMS die angeforderten Daten beschaffen, vor dem Anwender.
[...]
Ich kann mir schon ein Datenbankbasiertes Dateisystem vorstellen. Aber das wird, für den Anfänger mit Sicherheit nicht einfacher, als ein hirachisches.
Doch, wenn es richtig gemacht wird, dann ist es das. Dann muss man nämlich nicht mehr wissen, unter welchem Namen und nach welchen Ordnungskriterien man z. B. ein Angebot für ein neues Archiv vor einem halben Jahr abgelegt hat (Chronologisch? nach Kunden? nach Produkt? nach Preis? nach irgendeinem anderen Kriterium?) und was noch viel interessanter ist - Man kann das lokale Dateisystem ähnlich wie eine gute Suchmaschine verwenden: Das war doch mal was mit Archiv und Angebot - zeige mir mal, was da so auf der Pladde liegt!
Das ist richtig, und das ist ja auch der Vorteil der DB. Aber man muß z.B erst mal die DBSprache lernen. Wie etwas sortiert abgelegt wurde, interessiert ja nur insofern, wie schnell eine Suche sein wird. Allerdings wenn ich nach einen bestimmten Inhalt suche, wird es sicherlich auch länger dauern, oder ich muß eine Indexdatei über den Inhalt anlegen. [2] Hmmm.
Ob da nun ein relationales DMBS oder ein objektorientiertes DBMS oder ein ausgewachsenes Dokumentenmanagement- und Retrievalsystem im Hintergrund werkelt, ist erstmal nebensächlich. Fakt ist, dass die Schnittstelle zwischen Mensch und Dateisystem intuitiver zu bedienen sein wird. Da sind auch ausgeklügelte find-grep-sed-awk-Mechanismen bald am Ende, weil sie nur syntaktische Zusammenhänge herstellen können, keine semantischen.
Verstehe ich jetzt nicht. Mag ja sein, daß sich die Syntax von SQL lockerer anhört, ist sie aber nicht. Sie muß genauso strikt eingehalten werden, wie die von C. [1] Aber mich nur noch teilweise erinnert habe. So häufig ist BETWEEN ja nicht. [2] Bzw. das System für mich macht. Es bliebe ein dicker Overhead. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
On Die, 10 Dez 2002 at 03:56 (+0100), Bernd Brodesser wrote:
* Jan Trippler schrieb am 09.Dez.2002: [...]
Deshalb weicht eben die Insert-Syntax vom Select und Update ab.
Es weicht aber weit mehr ab, als es müßte.
Hä? Den Satz musst Du mir mal erklären. Nach welchen Kriterien definierst du *als es müsste*? Die Syntax ist so, dass man sie sich sehr leicht merken kann, weil sie wieder an die der natürlichen Sprache angelehnt ist.
AND dient genau wie in jeder anderen Sprache auch zum Verknüpfen von Bedingungen (bei SQL eben immer dann, wenn vorher ein WHERE stand) - OR wird übrigens haargenau so behandelt. Immer dann, wenn mehrere Spalten nacheinander aufgezählt werden (Select oder update), dann steht da ein Komma.
Stimmt schon. Was ich meinte [1] ist das AND bei BETWEEN. Da rollen sich bei mir die Zähennägel auf.
BETWEEN 15 AND 23
Was ist denn daran auszusetzen? Du sagst doch auch: Zwischen 1 _und_ 6 - und genauso ist die Syntax in SQL.
SQL ist im Gegensatz zu prozeduralen oder objektorientierten Programmiersprachen einfach zu lesen, weil sich die Syntax an die natürliche Sprache anlehnt:
Und genau das ist es. Natürliche Sprachen sind nicht logisch. Mag ja leichter zu lesen sein, aber nicht leichter zu schreiben.
Das ist Deine Meinung. Ich behaupte, dass sie viel leichter zu schreiben ist als jede Programmiersprache, weil die Syntax der des gesprochenen Satzes entspricht. Das entspricht im Übrigen auch meinen Beobachtungen bei Kunden.
select spalte1, spalte2 from tabelle where spalte_x > 100 and spalte_y <> 'Nikolaus'; update tabelle set spalte1 = 'A', spalte2 = 1 where spalte_y like 'Niko%' or spalte_z = '2002-12-24'; insert into tabelle values ('x', 'y', 2);
Was soll das into? Kann nach einem insert auch was anderes kommen?
Es soll die Les- und Schreibbarkeit verbessern. Natürlich kannst du auch *ins tabelle (x, y, z)* schreiben, nur dann ist eben die Erfassbarkeit nicht mehr so klar (obwohl Du gleich das Gegenteil behaupten wirst).
Bei einem update werden Spalten und Werte direkt zugeordnet, bei einem insert werden zuerst die Spaltennamen aufgezählt, dann die dazugehörige Werte.
Nur dann, wenn nicht alle Spalten mit Werten versorgt werden oder die Reihenfolge eine andere ist als in der Tabelle. Wie ich schon mal geschrieben habe: Ein Update soll einzelne Spalten einer durch Suchkriterien definierten Menge an Sätzen aktualisieren, der insert fügt einen kompletten neuen Satz ein (was anderes macht ja auch keinen Sinn). Warum soll also der Insert genauso aussehen wie der Update? Das wäre genauso, als wenn Du verlangen würdest, dass in C der fgets genauso aussieht wie der fread - sie machen doch auch ungefähr das Gleiche! Der delete wäre ja dann noch viel schlimmer - er hat überhaupt keine Spalten mehr, auweia: delete from tabelle where spaltex = 'Ostern'. Es macht hier einfach keinen Sinn, Spalten anzugeben, weil immer ein ganzer Satz gelöscht wird.
SQL (=Structured Query Language) ist mit dem Ziel designed worden, das _Wie_ vor dem Anwender der Sprache zu verbergen - er soll nur noch definieren müssen, _Was_ er als Ergebnis haben will - und das schafft diese Sprache prima.
Nein, ich muß mich an eine enge Syntax halten. In einer natürlichen Sprache bin ich viel freier. Wenn ich mich schon an eine enge Syntax halten muß, dann habe ich viel lieber was logisch aufgebautes, auch wenn es von der natürlich gesprochene Sprache abweicht.
1. Was hat die Einhaltung einer Syntax mit der Struktur von SQL zu tun? SQL ist nach wie vor eine formalisierte Sprache, das habe ich aber auch nicht bestritten. 2. Was an SQL ist unlogisch? 3. Meinst Du nicht, dass jemand, der _nicht_ programmieren kann, mit einer an natürliche Sprachen angelehnten Syntax viel schneller zurecht kommt als mit einer mehr oder weniger kryptischen Symbolik einer Programmiersprache?
Ich kann mir vorstellen, daß es für jemand, der nicht Englisch als Muttersprach hat, und auch keine Sprache, die dem Englischen sehr ähnlich ist, was das Deutsch nun mal ist, seine Probleme hat.
Aha, und der hat es dann mit setuid(), getpwnam() usw. ja so viel einfacher, ja? [...]
Das ist richtig, und das ist ja auch der Vorteil der DB. Aber man muß z.B erst mal die DBSprache lernen. Wie etwas sortiert abgelegt wurde, interessiert ja nur insofern, wie schnell eine Suche sein wird. Allerdings wenn ich nach einen bestimmten Inhalt suche, wird es sicherlich auch länger dauern, oder ich muß eine Indexdatei über den Inhalt anlegen. [2] Hmmm.
Seit wann musst Du z. B. bei Google eine DB-Sprache lernen oder einen Index anlegen? Du musst (solange zumindest, bis Computer die unscharfen Formulierungen der natürlichen Sprache einschätzen können) _immer_ ein gewisses Maß an Verabredungen (z. B. für die Formulierung von Suchanfragen) kennen. Und da ist die Schwelle für SQL deutlich niedriger als z. B. C (oder Perl ;-)
Ob da nun ein relationales DMBS oder ein objektorientiertes DBMS oder ein ausgewachsenes Dokumentenmanagement- und Retrievalsystem im Hintergrund werkelt, ist erstmal nebensächlich. Fakt ist, dass die Schnittstelle zwischen Mensch und Dateisystem intuitiver zu bedienen sein wird. Da sind auch ausgeklügelte find-grep-sed-awk-Mechanismen bald am Ende, weil sie nur syntaktische Zusammenhänge herstellen können, keine semantischen.
Verstehe ich jetzt nicht.
Lass einen grep z. B. auf den Begriff *high water mark* los - er wird nicht wissen, ob Du was über Hochwasserstände oder über Transaktionspuffer von RDBMS erfahren möchtest. Eine DB, die in der Lage ist, semantische Zusammenhänge herzustellen (ähnlich wie eine gute Spracherkennung), kann den Suchbegriff in einen Kontext einordnen, grep kann das nicht (nur in Verbindung mit anderen Funktionen, über die sich aber der Anfragende klar sein muss).
Mag ja sein, daß sich die Syntax von SQL lockerer anhört, ist sie aber nicht. Sie muß genauso strikt eingehalten werden, wie die von C.
Das ist aber doch kein Widerspruch zur Aussage, dass sie leichter zu erfassen ist.
[1] Aber mich nur noch teilweise erinnert habe. So häufig ist BETWEEN ja nicht.
[2] Bzw. das System für mich macht. Es bliebe ein dicker Overhead.
Bernd
-- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
* Jan Trippler schrieb am 10.Dez.2002:
On Die, 10 Dez 2002 at 03:56 (+0100), Bernd Brodesser wrote:
* Jan Trippler schrieb am 09.Dez.2002:
Stimmt schon. Was ich meinte [1] ist das AND bei BETWEEN. Da rollen sich bei mir die Zähennägel auf.
BETWEEN 15 AND 23
Was ist denn daran auszusetzen? Du sagst doch auch: Zwischen 1 _und_ 6 - und genauso ist die Syntax in SQL.
Ja, genau das sagt man, und da ist die deutsche Sprache genauso unlogisch wie die englische. Dieses und hat nichts mit dem logischen und zu tun. Ich glaube nicht, daß dies in jeder Sprache der Welt so ist. Ein Sprecher einer Sprache, die zwichen dieses und und dem logischen und unterscheidet, hat sicherlich schwirigkeiten dies zu verstehen. Mehr als irgend einen englischen Begriff, den man immer übersetzen kann. Eine Katze hat einen Schwanz mehr als keine Katze. Keine Katze hat zwei Schwänze, also hat eine Katze drei Schwänze. Hört sich logisch an, ist aber offensichtlich vollkommener Blödsinn. Das liegt daran, daß das Wort "keine" in zwei völlig verschiedene Bedeutungen benutzt wird.
Und genau das ist es. Natürliche Sprachen sind nicht logisch. Mag ja leichter zu lesen sein, aber nicht leichter zu schreiben.
Das ist Deine Meinung. Ich behaupte, dass sie viel leichter zu schreiben ist als jede Programmiersprache, weil die Syntax der des gesprochenen Satzes entspricht. Das entspricht im Übrigen auch meinen Beobachtungen bei Kunden.
Anscheinend sind wir da tatsächlich verschiedener Meinung. Mir ist es nicht unmittelbar verständlich, daß man bei einem INSERT INTO das Wort VALUES angeben muß, und bei einem UPDATE nicht. Ich weiß es mitlerweile, aber ist auch nicht unmittelbarer zugänglich als ein if then else fi.
Bei einem update werden Spalten und Werte direkt zugeordnet, bei einem insert werden zuerst die Spaltennamen aufgezählt, dann die dazugehörige Werte.
Nur dann, wenn nicht alle Spalten mit Werten versorgt werden oder die Reihenfolge eine andere ist als in der Tabelle. Wie ich schon mal geschrieben habe: Ein Update soll einzelne Spalten einer durch Suchkriterien definierten Menge an Sätzen aktualisieren, der insert fügt einen kompletten neuen Satz ein (was anderes macht ja auch keinen Sinn). Warum soll also der Insert genauso aussehen wie der Update? Das wäre genauso, als wenn Du verlangen würdest, dass in C der fgets genauso aussieht wie der fread - sie machen doch auch ungefähr das Gleiche!
Mir ist es schon öfters untergekommen, daß der User einen Datensatz eingibt. Wenn ein Schlüsselbegriff schon existiert, wird ein UPDATE gemacht, sonst ein INSERT. In dieser begnadeten Pro*C Schnittstelle von Oracle, in der SQL-Befehle per Präcompiler in C eingebettet wird, hatt man dann ständig mit unterschiedlichen Synatx zu kämpfen.
SQL (=Structured Query Language) ist mit dem Ziel designed worden, das _Wie_ vor dem Anwender der Sprache zu verbergen - er soll nur noch definieren müssen, _Was_ er als Ergebnis haben will - und das schafft diese Sprache prima.
Nein, ich muß mich an eine enge Syntax halten. In einer natürlichen Sprache bin ich viel freier. Wenn ich mich schon an eine enge Syntax halten muß, dann habe ich viel lieber was logisch aufgebautes, auch wenn es von der natürlich gesprochene Sprache abweicht.
1. Was hat die Einhaltung einer Syntax mit der Struktur von SQL zu tun? SQL ist nach wie vor eine formalisierte Sprache, das habe ich aber auch nicht bestritten. 2. Was an SQL ist unlogisch? 3. Meinst Du nicht, dass jemand, der _nicht_ programmieren kann, mit einer an natürliche Sprachen angelehnten Syntax viel schneller zurecht kommt als mit einer mehr oder weniger kryptischen Symbolik einer Programmiersprache?
Wer verwendet den heute noch SQL? Doch wohl nur noch Programmierer, oder etwa nicht. Alle anderen sind mit Eingabemasken und GUIs besser bedient.
Das ist richtig, und das ist ja auch der Vorteil der DB. Aber man muß z.B erst mal die DBSprache lernen. Wie etwas sortiert abgelegt wurde, interessiert ja nur insofern, wie schnell eine Suche sein wird. Allerdings wenn ich nach einen bestimmten Inhalt suche, wird es sicherlich auch länger dauern, oder ich muß eine Indexdatei über den Inhalt anlegen. [2] Hmmm.
Seit wann musst Du z. B. bei Google eine DB-Sprache lernen oder einen Index anlegen?
Ich habe doch in der Fußnote geschrieben, daß man den Index nicht selber anlegen muß, aber das System müßte es machen. Es entsteht ein gigantischer Overhead.
Du musst (solange zumindest, bis Computer die unscharfen Formulierungen der natürlichen Sprache einschätzen können) _immer_ ein gewisses Maß an Verabredungen (z. B. für die Formulierung von Suchanfragen) kennen. Und da ist die Schwelle für SQL deutlich niedriger als z. B. C (oder Perl ;-)
Ob da nun ein relationales DMBS oder ein objektorientiertes DBMS oder ein ausgewachsenes Dokumentenmanagement- und Retrievalsystem im Hintergrund werkelt, ist erstmal nebensächlich. Fakt ist, dass die Schnittstelle zwischen Mensch und Dateisystem intuitiver zu bedienen sein wird. Da sind auch ausgeklügelte find-grep-sed-awk-Mechanismen bald am Ende, weil sie nur syntaktische Zusammenhänge herstellen können, keine semantischen.
Verstehe ich jetzt nicht.
Lass einen grep z. B. auf den Begriff *high water mark* los - er wird nicht wissen, ob Du was über Hochwasserstände oder über Transaktionspuffer von RDBMS erfahren möchtest. Eine DB, die in der Lage ist, semantische Zusammenhänge herzustellen (ähnlich wie eine gute Spracherkennung), kann den Suchbegriff in einen Kontext einordnen, grep kann das nicht (nur in Verbindung mit anderen Funktionen, über die sich aber der Anfragende klar sein muss).
Äh? Inwieweit macht ein WHERE Column_x LIKE "%high water mark%" irgendwas anderes? Das sucht doch auch, genau wie ein grep nur nach einer Zeichenfolge, ohne den Inhalt zu verstehen.
Mag ja sein, daß sich die Syntax von SQL lockerer anhört, ist sie aber nicht. Sie muß genauso strikt eingehalten werden, wie die von C.
Das ist aber doch kein Widerspruch zur Aussage, dass sie leichter zu erfassen ist.
Das ist Geschmackssache. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
On Die, 10 Dez 2002 at 16:55 (+0100), Bernd Brodesser wrote:
* Jan Trippler schrieb am 10.Dez.2002:
On Die, 10 Dez 2002 at 03:56 (+0100), Bernd Brodesser wrote:
* Jan Trippler schrieb am 09.Dez.2002:
Stimmt schon. Was ich meinte [1] ist das AND bei BETWEEN. Da rollen sich bei mir die Zähennägel auf.
BETWEEN 15 AND 23
Was ist denn daran auszusetzen? Du sagst doch auch: Zwischen 1 _und_ 6 - und genauso ist die Syntax in SQL.
Ja, genau das sagt man, und da ist die deutsche Sprache genauso unlogisch wie die englische. Dieses und hat nichts mit dem logischen und zu tun. Ich glaube nicht, daß dies in jeder Sprache der Welt so ist. Ein Sprecher einer Sprache, die zwichen dieses und und dem logischen und unterscheidet, hat sicherlich schwirigkeiten dies zu verstehen. Mehr als irgend einen englischen Begriff, den man immer übersetzen kann.
Also weisst Du ... - Was soll das jetzt mit einer hypothetischen Sprache, bei der ein *Zwischen a und b* mit einem anderen *und* als bei einem logischen *und* geschrieben wird? Das ist doch Fantasterei! Wenn ein armer Suaheli jetzt grossen Stress dabei kriegt, SQL zu lernen, dann ist mir das völlig egal. Im Englischen ist das das gleiche AND (und an diese Sprache ist nunmal SQL angelehnt), im Deutschen ist es das gleiche UND und in SQL ist es ebenfalls das gleiche AND - das reicht mir. BTW: Das *und* bei dem *zwischen a und b* ist im Prinzip ein logisches, denn BETWEEEN ist einfach eine andere Bezeichnung für: größer gleich a _und_ kleiner gleich b. Tatsächlich kannst Du das BETWEEN in SQL dadurch ersetzen, dann brauchst Du Dich nicht mehr darüber zu ärgern. Ich verstehe Dich nicht, Deine Argumente sind für mich nicht logisch.
Eine Katze hat einen Schwanz mehr als keine Katze. Keine Katze hat zwei Schwänze, also hat eine Katze drei Schwänze.
Hört sich logisch an, ist aber offensichtlich vollkommener Blödsinn. Das liegt daran, daß das Wort "keine" in zwei völlig verschiedene Bedeutungen benutzt wird.
Dass die menschliche Sprache voller Mehrdeutigkeiten ist, das wissen wir. Na und? Java z. B. ist doch genauso mehrdeutig: System.out.println (4 + "2"); ergibt 42 System.out.println (4 + 2); ergibt 6 Sprachelemente ändern ihre Bereutung in Abhängigkeit vom Kontext - egal ob in Deutsch, Englisch, SQL, Java ... [insert / update]
Mir ist es schon öfters untergekommen, daß der User einen Datensatz eingibt. Wenn ein Schlüsselbegriff schon existiert, wird ein UPDATE gemacht, sonst ein INSERT.
In dieser begnadeten Pro*C Schnittstelle von Oracle, in der SQL-Befehle per Präcompiler in C eingebettet wird, hatt man dann ständig mit unterschiedlichen Synatx zu kämpfen.
Ich habe es ein paar Mails vorher schon mal geschrieben: SQL ist eine auf Ergebnis_mengen_ basierende Sprache. Der Update, der genau einen Satz angreift ist nur ein klitzekleiner Spezialfall der Anwendung des Befehls. Nicht umsonst wird bei Updates und Deletes die Anzahl der betroffenen Sätze (affected rows) zurückgeliefert. Der Fall, dass bei Eingabe eines existierenden Schlüssels in einer Maske automatisch ein Update gemacht wird, ist wieder ein Spezialfall. Normalerweise sollte dann zumindest eine Warnung / Sicherheitsabfrage erfolgen, weil es oft gar nicht gewünscht ist, existierende Sätze einfach zu überschreiben. Ich verstehe auch hier wieder nicht, worüber Du Dich eigentlich aufregst. [...]
Wer verwendet den heute noch SQL? Doch wohl nur noch Programmierer, oder etwa nicht. Alle anderen sind mit Eingabemasken und GUIs besser bedient.
Nö, eben nicht. Ich habe einige Admins / DV-Verantwortliche erlebt, die für ihre monatlichen Statistiken SQL einsetzten (weil GUIs eben immer nur einen Teil der Fähigkeiten von SQL zur Verfügung stellen). [...]
Ich habe doch in der Fußnote geschrieben, daß man den Index nicht selber anlegen muß, aber das System müßte es machen. Es entsteht ein gigantischer Overhead.
Ja, wie auch bei der locate-DB oder bei einem Thesaurus - immer wenn ich auf Daten zugreifen will, ohne den gesamten Datenbestand sequentiell durchforsten zu müssen, fällt ein solcher Overhead an. Das ist normal und gewollt. Ein Index dient der Performance-Steigerung und beinhaltet deshalb eine bestimmte Sicht auf einen Teil der indexierten Daten. [...]
Lass einen grep z. B. auf den Begriff *high water mark* los - er wird nicht wissen, ob Du was über Hochwasserstände oder über Transaktionspuffer von RDBMS erfahren möchtest. Eine DB, die in der Lage ist, semantische Zusammenhänge herzustellen (ähnlich wie eine gute Spracherkennung), kann den Suchbegriff in einen Kontext einordnen, grep kann das nicht (nur in Verbindung mit anderen Funktionen, über die sich aber der Anfragende klar sein muss).
Äh? Inwieweit macht ein WHERE Column_x LIKE "%high water mark%" irgendwas anderes? Das sucht doch auch, genau wie ein grep nur nach einer Zeichenfolge, ohne den Inhalt zu verstehen.
Wir haben uns doch hier über das *intelligente* Dateisystem aus dem Ausgangsposting unterhalten - oder? Es geht mir hier nicht um relationale DBMS und die Fähigkeiten von SQL. Wir erwarten doch nicht ernsthaft, dass der Benutzer eines solchen Dateisystems seine Daten per SQL sucht, oder?
Mag ja sein, daß sich die Syntax von SQL lockerer anhört, ist sie aber nicht. Sie muß genauso strikt eingehalten werden, wie die von C.
Das ist aber doch kein Widerspruch zur Aussage, dass sie leichter zu erfassen ist.
Das ist Geschmackssache.
Für mich: EOT - es bringt nichts. Jan
* Jan Trippler schrieb am 10.Dez.2002:
On Die, 10 Dez 2002 at 16:55 (+0100), Bernd Brodesser wrote:
* Jan Trippler schrieb am 10.Dez.2002:
On Die, 10 Dez 2002 at 03:56 (+0100), Bernd Brodesser wrote:
* Jan Trippler schrieb am 09.Dez.2002:
Ich habe es ein paar Mails vorher schon mal geschrieben: SQL ist eine auf Ergebnis_mengen_ basierende Sprache. Der Update, der genau einen Satz angreift ist nur ein klitzekleiner Spezialfall der Anwendung des Befehls. Nicht umsonst wird bei Updates und Deletes die Anzahl der betroffenen Sätze (affected rows) zurückgeliefert. Der Fall, dass bei Eingabe eines existierenden Schlüssels in einer Maske automatisch ein Update gemacht wird, ist wieder ein Spezialfall. Normalerweise sollte dann zumindest eine Warnung / Sicherheitsabfrage erfolgen, weil es oft gar nicht gewünscht ist, existierende Sätze einfach zu überschreiben.
Ich verstehe auch hier wieder nicht, worüber Du Dich eigentlich aufregst.
Ich habe wahrscheinlich zuviele Pro*C Programme geschrieben. Ich finde das schrecklich. Vor allem, weil es imho der C-Syntax widerspricht.
Wer verwendet den heute noch SQL? Doch wohl nur noch Programmierer, oder etwa nicht. Alle anderen sind mit Eingabemasken und GUIs besser bedient.
Nö, eben nicht. Ich habe einige Admins / DV-Verantwortliche erlebt, die für ihre monatlichen Statistiken SQL einsetzten (weil GUIs eben immer nur einen Teil der Fähigkeiten von SQL zur Verfügung stellen).
Meinte ich damit. Programmierer, Admins usw. Also Leute, die Programmieren können. Welcher Nur-Anwender benutzt den SQL? Die nehmen doch Eingabemasken.
Ich habe doch in der Fußnote geschrieben, daß man den Index nicht selber anlegen muß, aber das System müßte es machen. Es entsteht ein gigantischer Overhead.
Ja, wie auch bei der locate-DB oder bei einem Thesaurus - immer wenn ich auf Daten zugreifen will, ohne den gesamten Datenbestand sequentiell durchforsten zu müssen, fällt ein solcher Overhead an. Das ist normal und gewollt. Ein Index dient der Performance-Steigerung und beinhaltet deshalb eine bestimmte Sicht auf einen Teil der indexierten Daten.
Ja, schon klar. Bei locate handelt es sich aber nur um Dateinamen. Da ist kein großer Overhead da. Wenn aber ein Index, über den kompletten Inhalt der Dateien existieren soll, dann ist der Overhead doch sicherlich gigantisch.
Lass einen grep z. B. auf den Begriff *high water mark* los - er wird nicht wissen, ob Du was über Hochwasserstände oder über Transaktionspuffer von RDBMS erfahren möchtest. Eine DB, die in der Lage ist, semantische Zusammenhänge herzustellen (ähnlich wie eine gute Spracherkennung), kann den Suchbegriff in einen Kontext einordnen, grep kann das nicht (nur in Verbindung mit anderen Funktionen, über die sich aber der Anfragende klar sein muss).
Äh? Inwieweit macht ein WHERE Column_x LIKE "%high water mark%" irgendwas anderes? Das sucht doch auch, genau wie ein grep nur nach einer Zeichenfolge, ohne den Inhalt zu verstehen.
Wir haben uns doch hier über das *intelligente* Dateisystem aus dem Ausgangsposting unterhalten - oder? Es geht mir hier nicht um relationale DBMS und die Fähigkeiten von SQL. Wir erwarten doch nicht ernsthaft, dass der Benutzer eines solchen Dateisystems seine Daten per SQL sucht, oder?
Nein, natürlich nicht. Aber wie soll ich denn eine Semantik da hinein bekommen? Wenn es allgemeingültig sein soll, dann hat man wieder nur das Übliche. Was anderes wäre es, wenn jeder Sysadmin da was pflegt. Aber das ist denn richtig Arbeit. Oder sehe ich da was flasch? Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Hallo, On Tue, 10 Dec 2002, Bernd Brodesser wrote:
Ja, schon klar. Bei locate handelt es sich aber nur um Dateinamen. Da ist kein großer Overhead da. Wenn aber ein Index, über den kompletten Inhalt der Dateien existieren soll, dann ist der Overhead doch sicherlich gigantisch.
Muss nichtmal der Inhalt sein... Allein Indices ueber Pfad + saemtliche Attribute (wie von ls+lsattr angezeigt) duerften eine DB auf das x-fache der locatedb aufblaehen. Nimmt man dann noch ein paar Dateiformatspezifische Metadaten dazu, dann waechst die DB sehr schnell. Man schaue sich einfach z.B. mal die von gtktalog angelegte DB zu _einer_ CD, oder die RPM-DBs. Letztere haben bei mir z.B. z.Z. 97MB fuer 1085 Pakete... Und 'rpm -q' ist nicht allzu performant... Sowas als FS??? Nein, wie schon "upthread" geschrieben, danke, darauf kann ich verzichten... -dnh -- Die Bezeichnung Newbie ist also, wie schon soviele vor mir äußerten, keine Beleidigung sondern einfach eine Zustandsbeschreibung für einen bestimmten Wissensbereich. -- Jens Ott in suse-linux
Hallo Jan, On Tue, 10 Dec 2002, Jan Trippler wrote:
Dass die menschliche Sprache voller Mehrdeutigkeiten ist, das wissen wir. Na und? Java z. B. ist doch genauso mehrdeutig: System.out.println (4 + "2"); ergibt 42 System.out.println (4 + 2); ergibt 6
Nein. Das ist groesstenteils logisch. Das ist 1. eine Konkatenation einer Ziffer und eines Strings, und 2. eine Addition, deren Ergebnis ausgeben wird. Unlogisch ist dabei die "Auswertungsreihenfolge" (deren Details ich bei Java nur anhand des Ergebnisses raten kann), naemlich dass zuerst der Integer 4 zum string/char umgewandelt wird, dann mit dem string "2" konkateniert wird und dann der gesamte String ausgegeben wird. Vgl: perl -e "print 4 . 2, ' ', 4 . '2', ' ', 4 . \"2\", ' ', 4 + 2, ' ', 4 + '2', ' ', 4 + \"2\", ' ', 4+ord(2),' ',4+ord('2'),' ',4+ord(\"2\"), \"\n\"" Das ist uebrigens eins der Dinge, die ich an Perl mag -- einen expliziten Konkatenationsoperator ('.'), der ungleich dem Sequenz- (',') und ungleich dem Additionsoperator ('+') ist.
Sprachelemente ändern ihre Bereutung in Abhängigkeit vom Kontext - egal ob in Deutsch, Englisch, SQL, Java ...
*hehe*, perl(!). Vgl: perl -e 'print "" . @ARGV, " ", @ARGV, "\n"' foo bar
Für mich: EOT - es bringt nichts.
Für mich (dieser Subthread mit leicht anderem Thema) nicht *g* -d'?÷îáïîöç?Êèæç îáâçõòå Ðòåù Èîðøòå?¯÷îáïîöç?'nh -- If you're looking for me, I'll be the quivering pile of jelly wobbling pitifully in the corner over there. -- Stuart Lamble, in the SDM
* David Haller schrieb am 10.Dez.2002:
Das ist uebrigens eins der Dinge, die ich an Perl mag -- einen expliziten Konkatenationsoperator ('.'), der ungleich dem Sequenz- (',') und ungleich dem Additionsoperator ('+') ist.
oh ja, laß uns über perl sprechen. ;) perl ist was feines, hat leider nur einen Nachteil: Es erlaubt zuviel. Mal ganz ehrlich, würdest Du gerne an einem in perl geschriebenen Kernel arbeiten? Laß mal die Tatsache weg, daß es nicht sonderlich sinnig ist, einen Kernel in einer Skriptsprache zu schreiben. Ich meine schlicht die Tatsache, wenn eine Millionen Zeilen Quelltext von hunderte verschiedene Leute geschrieben werden. Ich glaube, bei perl blickt da denn keiner mehr durch. Mit perl kann man bösartigen Code schreiben. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
Hallo, On Wed, 11 Dec 2002, Bernd Brodesser wrote:
* David Haller schrieb am 10.Dez.2002:
Das ist uebrigens eins der Dinge, die ich an Perl mag -- einen expliziten Konkatenationsoperator ('.'), der ungleich dem Sequenz- (',') und ungleich dem Additionsoperator ('+') ist.
oh ja, laß uns über perl sprechen. ;) perl ist was feines, hat leider nur einen Nachteil: Es erlaubt zuviel.
Finde ich nicht.
Mal ganz ehrlich, würdest Du gerne an einem in perl geschriebenen Kernel arbeiten?
Nein.
meine schlicht die Tatsache, wenn eine Millionen Zeilen Quelltext von hunderte verschiedene Leute geschrieben werden.
Und was ist mit dem Kernel? Schonmal "MAINTAINERS" angeschaut? Und mal ein wc -l ueber die Kernelquellen gemacht? Perl ist wesentlich kleiner. Und bei den Modulen die man verwenden will kann man ja vorher reinschauen.
Ich glaube, bei perl blickt da denn keiner mehr durch. Mit perl kann man bösartigen Code schreiben.
Das geht mit C und anderem auch. -dnh -- I've always taken the position that if you can't find anything bad to say about a language or an operating system then you don't understand it. -- S. Metz in the Monastery
Hallo David, * David Haller schrieb am 11.Dez.2002:
On Wed, 11 Dec 2002, Bernd Brodesser wrote:
oh ja, laß uns über perl sprechen. ;) perl ist was feines, hat leider nur einen Nachteil: Es erlaubt zuviel.
Finde ich nicht.
Mal ganz ehrlich, würdest Du gerne an einem in perl geschriebenen Kernel arbeiten?
Nein.
meine schlicht die Tatsache, wenn eine Millionen Zeilen Quelltext von hunderte verschiedene Leute geschrieben werden.
Und was ist mit dem Kernel? Schonmal "MAINTAINERS" angeschaut? Und mal ein wc -l ueber die Kernelquellen gemacht? Perl ist wesentlich kleiner. Und bei den Modulen die man verwenden will kann man ja vorher reinschauen.
Reden wir aneinander vorbei? Was ich meine, wenn Du etwas an einem Perlskript ändern müßtest, das nicht Du geschrieben hast, sondern ein anderer. Dieses Skript vielleicht noch auf andere Skripte zugreift, die noch andere geschrieben haben. Um eine tiefgreifende Änderung vorzunehmen, mußt Du Dir diese Skripte alle anschauen und auf evtl. Bugs kontrollieren. Und das ganze vielleicht auch noch unter Zeitdruck. Jeder hat einen anderen Stil zu programmieren. Bei perl ist es viel schwieriger durchzusteigen, als etwa bei C.
Ich glaube, bei perl blickt da denn keiner mehr durch. Mit perl kann man bösartigen Code schreiben.
Das geht mit C und anderem auch.
Ja, es geht auch mit C, wenn man genug bösen Willen hat. Und es gibt auch Fallstricke bei C. Aber bei perl hat man das, auch ohne bösen Willen, viel schneller. Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Moin,
* Bernd Brodesser
Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein.
Stimmt; das kann aber auch sehr schick sein, weil es der menschlichen Sprache näher ist. Thorsten -- There is no drug known to man which becomes safer when its production and distribution are handed over to criminals.
* Am Don, 12 Dez 2002 schrieb Thorsten Haude:
Moin,
* Bernd Brodesser
[2002-12-12 05:44]: Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein.
Stimmt; das kann aber auch sehr schick sein, weil es der menschlichen Sprache näher ist.
Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
* Christoph Maurer schrieb am 12.Dez.2002:
* Am Don, 12 Dez 2002 schrieb Thorsten Haude:
* Bernd Brodesser
[2002-12-12 05:44]:
Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein.
Stimmt; das kann aber auch sehr schick sein, weil es der menschlichen Sprache näher ist.
Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch.
Genauso sehe ich es auch. Perl ist eine tolle Skriptsprache. Auch größere Skripte kann man damit gut schreiben. Man muß ja Sachen, die man nicht mag, nicht verwenden. Aber wenn es sich um ein wirklich großes Projekt handelt, an dem man nicht allein, sondern mit sehr vielen Menschen arbeitet, dann wird es unübersichtlich. Und zwar wesentlich unübersichtlicher, als es ohnehin Not tut. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
Moin,
* Christoph Maurer
* Am Don, 12 Dez 2002 schrieb Thorsten Haude:
* Bernd Brodesser
[2002-12-12 05:44]: Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein.
Stimmt; das kann aber auch sehr schick sein, weil es der menschlichen Sprache näher ist.
Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch.
Ich sehe nicht, wo das schaden könnte. Man kann mit typischen Perlismen schon sehr gut lesbare Dinge schreiben, zB.: open $file or die; Thorsten -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. - Grundgesetz, Artikel 10, Abs. 1
* Thorsten Haude schrieb am 12.Dez.2002:
* Christoph Maurer
[2002-12-12 10:03]: * Am Don, 12 Dez 2002 schrieb Thorsten Haude:
* Bernd Brodesser
[2002-12-12 05:44]: Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein.
Stimmt; das kann aber auch sehr schick sein, weil es der menschlichen Sprache näher ist.
Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch.
Ich sehe nicht, wo das schaden könnte. Man kann mit typischen Perlismen schon sehr gut lesbare Dinge schreiben, zB.: open $file or die;
Ja, man *kann* Wenn Du aber ein Projekt hast, an dem hundert Leute schreiben, da muß man auch durchblicken, was die anderen so schreiben. Zumindest bei vielen. Und da kann es ganz schön eng werden. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Moin,
* Bernd Brodesser
* Thorsten Haude schrieb am 12.Dez.2002:
* Christoph Maurer
[2002-12-12 10:03]: Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch.
Ich sehe nicht, wo das schaden könnte. Man kann mit typischen Perlismen schon sehr gut lesbare Dinge schreiben, zB.: open $file or die;
Ja, man *kann* Wenn Du aber ein Projekt hast, an dem hundert Leute schreiben, da muß man auch durchblicken, was die anderen so schreiben. Zumindest bei vielen. Und da kann es ganz schön eng werden.
Mit scheint, Du lehnst die Sprache grundsätzlich ab, weil sie in bestimmten Situationen nicht ideal ist. C taugt also nichts, weil man damit keine Skripte schreiben kann. Thorsten -- A: Top posters Q: What's the most annoying thing about email these days?
* Am Don, 12 Dez 2002 schrieb Thorsten Haude:
* Bernd Brodesser
[2002-12-12 10:29]: * Thorsten Haude schrieb am 12.Dez.2002:
* Christoph Maurer
[2002-12-12 10:03]: Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch.
Ich sehe nicht, wo das schaden könnte. Man kann mit typischen Perlismen schon sehr gut lesbare Dinge schreiben, zB.: open $file or die;
Ja, man *kann* Wenn Du aber ein Projekt hast, an dem hundert Leute schreiben, da muß man auch durchblicken, was die anderen so schreiben. Zumindest bei vielen. Und da kann es ganz schön eng werden.
Mit scheint, Du lehnst die Sprache grundsätzlich ab, weil sie in bestimmten Situationen nicht ideal ist. C taugt also nichts, weil man damit keine Skripte schreiben kann.
Du liest Bernds Mails nicht: In einer Parallel-Mail schreibt er: "Perl ist eine tolle Skriptsprache. Auch größere Skripte kann man damit gut schreiben. Man muß ja Sachen, die man nicht mag, nicht verwenden." Aber das es sicher aufgrund der vielen Möglichkeiten ein Problem zu erschlagen und der unzähligen denkbaren Varianten, dreckiges Perl zu programmieren, ein Problem werden kann, mit vielen verteilten Programmieren an einem sehr großen (>> 100.000 Zeilen) Projekt zu arbeiten und daß C (oder aus meiner Sicht vor allem C++) dazu besser geeignet ist, dazu stehe ich. Deswegen mag ich perl trotzdem, aber ich mag auch bash, trotzdem würde ich nicht jedes Programm in bash schreiben. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
* Thorsten Haude schrieb am 12.Dez.2002:
Moin,
* Christoph Maurer
[2002-12-12 11:10]: Du liest Bernds Mails nicht:
Stimmt, ich habe nicht bemerkt, daß Ihr getauscht habt.
? Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
* Thorsten Haude schrieb am 12.Dez.2002:
* Bernd Brodesser
[2002-12-12 10:29]:
Ja, man *kann* Wenn Du aber ein Projekt hast, an dem hundert Leute schreiben, da muß man auch durchblicken, was die anderen so schreiben. Zumindest bei vielen. Und da kann es ganz schön eng werden.
Mit scheint, Du lehnst die Sprache grundsätzlich ab, weil sie in bestimmten Situationen nicht ideal ist. C taugt also nichts, weil man damit keine Skripte schreiben kann.
Blödsinn! Ich mag perl und schreibe viel in perl. Nun gut, gegen David habe ich sicherlich keine Chance. ;) perl hat auch enorme Vorteile. So z.B die regular expressions, die vor perl, und teilweise noch heute, sehr unter verschiedener Definition, verschiedener tools leiden. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
Hallo, ich habe leider gestern etwas vorschnell auf loeschen gedrueckt, deshalb jetzt das etwas unsaubere Replay.
On Tue, 10 Dec 2002, Jan Trippler wrote:
Für mich: EOT - es bringt nichts.
Also ich empfang diesen Thread als einen der interessantesten der letzten Zeit. Beste Gruesse, Heinz. -- http://www.pahlke-online.de/reisenews/ http://www.Pahlke-KunstWebDesign.de/
Hallo, On Mon, 09 Dec 2002, Bernd Brodesser wrote:
* David Haller schrieb am 07.Dez.2002:
On Sat, 07 Dec 2002, Michael Gebhart wrote: ["WinFS" in ner SQL-DB?] Mit MS-SQL? *muhahaha*
Sicherlich kein MS-SQL
[ ] Du kennst M$. Natuerlich damit. Oder Access. *wuerg*
und auch kein MySQL.
Ok.
Wenn Datenbank, dann was vernünftiges. Oracle oder DB2 oder so. Aber da fängt das Problem schon an. Wenn man es Professionell einsetzt, als damit Geld machen will, dann will Oracle und wahrscheinlich auch IBM, für ihre Datenbank sehr, sehr viel Geld.
[ ] Du kennst M$.
Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend.
Bei UNIX gibt es schon seit ewigen Zeiten keine Laufwerkbuchstaben. Das ist nun wirklich nichts Neues.
Eben. Nur kann M$ das nun als tolle Innovation verkaufen...
Ich kann mir schon ein Datenbankbasiertes Dateisystem vorstellen. Aber das wird, für den Anfänger mit Sicherheit nicht einfacher, als ein hirachisches.
Ack. Auch in einer DB muessen die Daten irgendwie strukturiert abgelegt werden, und eben dabei, der Strukturiertheit liegt "das Problem"...
Achso, den Festplattenherstellern duerfte das natuerlich gefallen, endlich eine Anwendung, die die neuen Kapazitaeten auslastet. 100 MB Daten, 500 MB Metadaten *rotfl*.
Nun ja, sehr viele Dateien verbraten mehr I-Node, als tatsächliche Daten. Ich weiß auch nicht, warum ein Datenbankorientiertes System soviel Overhead produzieren sollte.
Indizes! Ansonsten waere ne DB aehnlich schnell wie ein find auf ext2. Und damit das ganze "DBFS" sinnvoll ist, muessten mehr Metainformationen als z.B. bei ext2 oder FAT/NTFS abgelegt werden, und diese wuerden natuerlich (mit den Indizes darauf) mehr Platz verbrauchen.
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.
locate brauche ich nur sehr selten. Da kann man ja nur nach den Namen suchen, nicht aber nach Datum, Größe, oder was auch immer. find kann das, braucht aber ewig, besonders wenn nach Inhalt gesucht wird. ;)
Ein locate <extension> | grep ... | xargs grep -H ... ist i.d.R. deutlich schneller als ein analoges find ... { -exec , | xargs } grep -H ... Natuerlich bedingt das, dass z.B. Extensionen vergeben werden, oder "passende" Verzeichnisse (-bestandteile) verwendet werden. Lege ich z.B. alle Quelltexte in Verzeichnissen ab, in denen irgendwo ein '/src/' vorkommt, so ist ein 'locate /src/ | ...' wesentlich schneller als ein 'find / ...'. Passend mit grep auf Dateinamen und/oder -inhalte kombiniert... Und selbst wenn man aus der locate-Ausgabe noch die Verzeichnisnamen extrahiert (man dirname), und diese dann noch nach nem '| sort -u' noch an find verfuettert... Die Frage ist, wie man die Tools optimal kombiniert, nicht welches man davon (exklusiv) verwendet ;) Mein System, mit (ohne das vergammelte Win 0.95) z.Z. gut 84 GB ist eigentlich ein grosses Chaos, da ueber Jahre hinweg gewachsen (von IIRC mal 2 GB) und immer wieder auf neue HDs umgezogen, mit Doubletten/Backups, mit aus Platzmangel "kurzfristig" auf ne andere Partition/HD ausgelagertem Kram usw. usw... Und dennoch finde ich mit einem locate ... | egrep '\.(foo|bar)' i.d.R. das gesuchte innerhalb von Sekunden, da ich gewisse "Konventionen"/"Kriterien" immer einhalte. Und genau danach kann ich suchen. Z.B. locate foo | grep '/tex-archive/' Das findet mir nur Kram von CTAN ;) Oder: locate foo | grep '^/win[c-f]/' findet mir nur was auf meinen Win-Partitionen...
Achso: Was "Anfaenger" verwirrt sind schlicht unpassende Analogien, wenn "man" versucht ihnen das zu erklaeren. Je nach "Hintergrund" der Person sind eben unterschiedliche Analogien angebracht. Schwieriger wird's erst bei der Unix-spezifischen Variante "alles ist eine Datei" (also insbesondere auch Verzeichnisse, Devices (wie Festplatten!) usw. aber das kann man "rausschieben").
Was ist denn daran schwierig? Ist doch viel einfacher als alles andere.
Ja, "eigentlich" schon... Aber mach $DAU dann man den (subtilen) Unterschied zwischen "regular file", "directory", "char device", "block device", "fifo", "socket" usw. klar... Ne, da ist mir (erstmal) die Trennung "Datei", "Verzeichnis" und "anderes" lieber...
Klar, daß eine Festplatte eine Datei ist, muß man vielleicht schon mal schlucken.
Eben. ;)
Aber Grundsätzlich, wenn einem sowas als nicht einfach erscheint, dann kann ich mir das nur durch verbildung durch andere OS erklären.
Ack. Aber: $DAU kapiert auch dort nicht so recht was denn nun Dateien und Verzeichnisse sind. Fuer $DAU ist eine Datei z.B. das, was er in Word sieht. Nicht die Datei auf der HD, nein, das, was Word _anzeigt_! Ganz zu schweigen davon, wenn MacOS und die "Resource Forks" mit ins Spiel kommen *eg*
Ansonsten kann man sich meist wunderbar mit der "Buero"-Analogie behelfen und Verzeichnisse sind einfach Aktenordner und -schraenke ;)
CPU&-Register: die Person (mit Kurzzeitgedaechnis)
Ich darf doch schwer bitten. Wenn ich morgens aufwache, brauche ich nicht erst Aktenordner durchzulesen. Ich kann mich auch so erinnern.
*lol* Denk dir einfach ein 'dump(regs, archive)' vor, und ein 'restore(archive, regs)' nach dem schlafen ;) Und zwischendrin ein "mix(regs, archive, /dev/random)" ;) Und ja, das mit dem Gedaechnis ist eine eher bloede Analogie. Der Rest passt besser.
L1-Cache: Schreibtischoberflaeche/-unterlage L2-Cache: Ablagefaecher auf dem Schreibtisch RAM: Regale/Aktenschraenke im Arbeitszimmer Festplatte: Archiv im Keller Tapes etc: Backup-Archiv in $FILIALE / $BANK o.ae.
Und "Verzeichnisse" sind also schlicht ein "Ordnungsmittel" wie Hefter/Ordner/Schraenke, in die man "Akten" (-blaetter) einsortieren kann.
Ganz generell, Linux ist nicht nur für Anfänger geschrieben. Ganz im Gegenteil.
Ack. Allerdings: Linux hat (fuer mich) den angenehmen Nebeneffekt, dass man sehr viel ueber Rechner lernen kann... Allein sich mal dmesg in aller Ruhe reinzuziehen... (mit Doku, und evtl. auch mal einen Blick in die Kernelsourcen)... Da lernt man viel davon, was der Rechner denn eigentlich so macht, wenn er ein OS bootet... "Oh, hallo ersma... ick schein zu laufen... Denn wolle mer ma kucken, wat hier so los is... also erstmal isset gut, wenn icke ne CPU finden taet. Denn auf irgendwat schein ick jo ausjefuehrt zu wern, nae? Und denn, was hammwer denn noch so allet? Ah, eine HD? Jut. Denn kucken wer ma, wat da so allet druff is... (usw. ;) ... ah, unn wat zum Krachmachen hamwer oooch?..." -dnh -- Perl is a mess. But that's okay, because the problem space is also a mess. -- Larry Wall
* David Haller schrieb am 10.Dez.2002:
On Mon, 09 Dec 2002, Bernd Brodesser wrote:
* David Haller schrieb am 07.Dez.2002:
On Sat, 07 Dec 2002, Michael Gebhart wrote: ["WinFS" in ner SQL-DB?] Mit MS-SQL? *muhahaha*
Sicherlich kein MS-SQL
[ ] Du kennst M$.
Natuerlich damit. Oder Access. *wuerg*
ich sprach nicht von M$, sondern ganz allgemein, ob es sinnig ist, ein Dateisystem auf DB-Basis aufzubauen, oder nicht. Daher auch meine Forderung, eine vernünftige DB zu nehmen. Wenn ich nämlich eine solche brauche, und dann noch eine daneben baue, dann ist das doch völlig daneben. ;)
Ich kann mir schon ein Datenbankbasiertes Dateisystem vorstellen. Aber das wird, für den Anfänger mit Sicherheit nicht einfacher, als ein hirachisches.
Ack. Auch in einer DB muessen die Daten irgendwie strukturiert abgelegt werden, und eben dabei, der Strukturiertheit liegt "das Problem"...
Ja. Aber es gibt Tabellen und Views.
Nun ja, sehr viele Dateien verbraten mehr I-Node, als tatsächliche Daten. Ich weiß auch nicht, warum ein Datenbankorientiertes System soviel Overhead produzieren sollte.
Indizes! Ansonsten waere ne DB aehnlich schnell wie ein find auf ext2.
Doch. Bei Inhalten sehe ich es auf Problematisch. Aber ein Index über Datum oder Größe wird ja wohl nicht so sehr das Problem sein.
Und damit das ganze "DBFS" sinnvoll ist, muessten mehr Metainformationen als z.B. bei ext2 oder FAT/NTFS abgelegt werden, und diese wuerden natuerlich (mit den Indizes darauf) mehr Platz verbrauchen.
Ja, aber nicht viel.
Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.
locate brauche ich nur sehr selten. Da kann man ja nur nach den Namen suchen, nicht aber nach Datum, Größe, oder was auch immer. find kann das, braucht aber ewig, besonders wenn nach Inhalt gesucht wird. ;)
Ein
locate <extension> | grep ... | xargs grep -H ...
ist i.d.R. deutlich schneller als ein analoges
find ... { -exec , | xargs } grep -H ...
Ja, aber kommt recht selten vor. Entweder gleich ein grep -r oder ein einfachs ls reicht. Viel häufiger suche ich nach Dateien, die ich gestern geändert habe, weiß aber leider total nicht mehr, wo ich suchen soll. Ok, so oft kommt das auch nicht vor. Trotzdem, ein locate hilft da nicht. Was bei mir wirklich häufiger vorkommt, daß ich irgendwas mit yast installieren, yast meint, dann müsse man aber auch noch dies und das installieren, ich sage OK. Später stelle ich fest, daß es doch nicht das ist, was ich brauche und wieder deinstalliere. Das eigentliche Paket, daß ich installiert habe, weiß ich noch, aber die Dinger, die yast mir vorgeschlagen hat - no Chance.
Natuerlich bedingt das, dass z.B. Extensionen vergeben werden, oder "passende" Verzeichnisse (-bestandteile) verwendet werden. Lege ich z.B. alle Quelltexte in Verzeichnissen ab, in denen irgendwo ein '/src/' vorkommt, so ist ein 'locate /src/ | ...' wesentlich schneller als ein 'find / ...'. Passend mit grep auf Dateinamen und/oder -inhalte kombiniert... Und selbst wenn man aus der locate-Ausgabe noch die Verzeichnisnamen extrahiert (man dirname), und diese dann noch nach nem '| sort -u' noch an find verfuettert...
Die Frage ist, wie man die Tools optimal kombiniert, nicht welches man davon (exklusiv) verwendet ;)
ACK
Achso: Was "Anfaenger" verwirrt sind schlicht unpassende Analogien, wenn "man" versucht ihnen das zu erklaeren. Je nach "Hintergrund" der Person sind eben unterschiedliche Analogien angebracht. Schwieriger wird's erst bei der Unix-spezifischen Variante "alles ist eine Datei" (also insbesondere auch Verzeichnisse, Devices (wie Festplatten!) usw. aber das kann man "rausschieben").
Was ist denn daran schwierig? Ist doch viel einfacher als alles andere.
Ja, "eigentlich" schon... Aber mach $DAU dann man den (subtilen) Unterschied zwischen "regular file", "directory", "char device", "block device", "fifo", "socket" usw. klar... Ne, da ist mir (erstmal) die Trennung "Datei", "Verzeichnis" und "anderes" lieber...
Groß den Unterschied von Character Device und Block Device zu erklären halte ich auch nicht für sonderlich Sinnvoll.
Fuer $DAU ist eine Datei z.B. das, was er in Word sieht. Nicht die Datei auf der HD, nein, das, was Word _anzeigt_!
Bei vi oder auch emacs, stimmt es ja auch weitgehend überein. ;) Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
Hallo, On Tue, 10 Dec 2002, Bernd Brodesser wrote:
* David Haller schrieb am 10.Dez.2002: [..] Viel häufiger suche ich nach Dateien, die ich gestern geändert habe, weiß aber leider total nicht mehr, wo ich suchen soll.
Naja, ich hab nur eine handvoll Verzeichnisse, in denen ich arbeite, darin liegen naturgemaess nicht allzuviele Dateien, und dann kann man mit find schnell die Dateien finden.
Was bei mir wirklich häufiger vorkommt, daß ich irgendwas mit yast installieren, yast meint, dann müsse man aber auch noch dies und das installieren, ich sage OK. Später stelle ich fest, daß es doch nicht das ist, was ich brauche und wieder deinstalliere. Das eigentliche Paket, daß ich installiert habe, weiß ich noch, aber die Dinger, die yast mir vorgeschlagen hat - no Chance.
Doch. man rpm und rpm --querytags (und das RPM-Book). rpm -qa --queryformat \ "%{installtime} %{installtime:date} %{name}\n" | sort -n Ein cut -d' ' -f2- falls man die "Epoch"-Zeitangabe weghaben will und/oder ein 'tail -20' kann man ggfs. auch anhaengen... [..]
Fuer $DAU ist eine Datei z.B. das, was er in Word sieht. Nicht die Datei auf der HD, nein, das, was Word _anzeigt_!
Bei vi oder auch emacs, stimmt es ja auch weitgehend überein. ;)
*hehe* Aber auch da ist die Datei nicht die Editoranzeige. Besonders auffaellig ist das beim xemacs, der aktuelle Aenderungen in einer _anderen_ Datei speichert... Und erst beim abspeichern landen die Aenderungen in der urspruenglichen Datei ;) -dnh -- How the boss came up with this brilliant idea is so fscking far beyond my logic, that in order to see it clearly, I would have to drain 50% of the blood from my body, and ingest LSD laced with PCP and turpentine. -- Stephen Edwards
* David Haller schrieb am 10.Dez.2002:
On Tue, 10 Dec 2002, Bernd Brodesser wrote:
* David Haller schrieb am 10.Dez.2002:
Viel häufiger suche ich nach Dateien, die ich gestern geändert habe, weiß aber leider total nicht mehr, wo ich suchen soll.
Naja, ich hab nur eine handvoll Verzeichnisse, in denen ich arbeite, darin liegen naturgemaess nicht allzuviele Dateien, und dann kann man mit find schnell die Dateien finden.
Ja klar. Da brauche ich noch nicht mal ein find, das finde ich auch so. Aber manchmal muß man irgendwo eine Datei ändern. Hatte da z.B mal irgendwo eine Headerdatei geändert. Ok, war auch recht schnell mit find /usr/include ... gefunden. Viel netter noch, wenn man ein tarball auspackt, und der installiert direkt irgendwo hin. Ja, ich weiß, man kann sich das vorher mit tar -tzf ansehen.
Was bei mir wirklich häufiger vorkommt, daß ich irgendwas mit yast installieren, yast meint, dann müsse man aber auch noch dies und das installieren, ich sage OK. Später stelle ich fest, daß es doch nicht das ist, was ich brauche und wieder deinstalliere. Das eigentliche Paket, daß ich installiert habe, weiß ich noch, aber die Dinger, die yast mir vorgeschlagen hat - no Chance.
Doch. man rpm und rpm --querytags (und das RPM-Book).
rpm -qa --queryformat \ "%{installtime} %{installtime:date} %{name}\n" | sort -n
Ein cut -d' ' -f2- falls man die "Epoch"-Zeitangabe weghaben will und/oder ein 'tail -20' kann man ggfs. auch anhaengen...
Eh, gut. Ich glaube, irgendwann muß ich mich doch nochmal mit rpm beschäftigen. ;) Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Michael Gebhart
ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund, die komplexe Abfragen ermöglicht. Automatisch fällt also das windows-typische C:\ D:\ etc. weg. Wie genau es aussehen wird, weiß ich nicht, aber wenn es so ist, wie ich es mir vorstelle, dürfte es durchaus innovativ und von der Struktur den Linuxdateisystemen überlegen sein. Meine Vorstellung ist, dass es keine Verzeichnisse mehr gibt, sondern einfach Dateien, die sortiert dargestellt werden können. Nach Autor, Titel etc.
Folgende Abfragen wären möglich: Liste alle Dokumente auf, die ich in den letzten 5 Tagen erstellt habe und auf die von den Programmen X, Y und Z zugriffen wurde.
Oder: Lege aus den Bildern vom 10-12.11.02, die von den Usern X und Y gesehen wurden eine Bildergalerie an.
Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend. Verzeichnisse verwirren Anfänger immer wieder. Wenn man so einfach alle Dateien sortiert und strukturiert, je nach Art der Abfrage aufgelistet bekommen würde, hätten die wenigstens Probleme einen PC zu bedienen. Was haltet ihr von dem neuen Dateisystem, oder der Idee prinzipiell? Wäre so etwas nicht etwas revolutionäres, was sich auch Linux zu eigen machen könnte?
Ich halt' nix (besser nicht viel) davon. Einige Gründe: C:, D: damit haben doch nur M$-Benutzer Probleme. In Unices gibt es das nicht. Insb. nicht für Anfänger; und Administratoren sollten wissen was Mount-Points etc,. sind. Ein Inhaltsbasierte und Benutzungsorientiertes Finden von Dateien ist schon ok. Aber so einfach ist das auch wieder nicht, denn wie geht man mit Mehrdeutigkeiten um. Ja man kann das Lösen, aber kann der vielzitierte Anfänger das auch noch verstehen? Schon mal versucht sowas wie Heuristiken etc. einem Anfänger zu erklären? (ich schon). Wenn man so was will, kann man es ja in Konquerer einbauen, mit nettem Klicke-di-Klick Interface. Aber ein Dateisystem soll zuverlässig, schnell und skalierbar sein und sonst nix. Der Rest ist eine Sache des Anzeigens der Information. Ausser Anfängern gibt es ja auch noch professionelle Benutzer, die z.B. Software entwickeln. Die brauchen andere Tools. (Vergleiche die Bedieneranleitung und Bordwerkzeuge im Auto mit den Handbüchern und Werkzeugen in einer Autowerkstatt). Ich ziehe für diese Art von Aufgaben die Kommandozeile vor, denn das ist schneller und ___reproduzierbarer___ als mittels GUI.
jenach Art der Abfrage aufgelistet bekommen würde, hätten die wenigstens Probleme einen PC zu bedienen.
Benutzer werden _IMMER_ Probleme haben, nämlich dann, wenn sie nicht geschult sind! Das Problem der Nichtbenutzbarkeit von PC's (ob Linux oder M$) ist doch: - 1. es fehlt an Ausbildung. Und das nicht nur weil die Benutzer dies nicht wollen, sondern weil die Hersteller und Softwareproduzenten sagen, das sei nicht notwendig. - 2. es fehlt an vernüntigen Schulungsunterlagen, die _kostenlos_ den Produkten beigegeben werden. (Und hier ist gerade KDE ein hervorrangendes Beispiel: die wenigsten Proggi's haben eine vernünftige Hilfe; Programmieren macht halt mehr Spaß, als Doku schreiben). So nun genug des OT Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 9204871 Fax: +49(721) 24874 juergen@informatik-vollmer.de,vollmer@cocolab.de,Juergen.Vollmer@acm.org www.informatik-vollmer.de
Moin,
* Jürgen Vollmer
Michael Gebhart
: ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. C:, D: damit haben doch nur M$-Benutzer Probleme. In Unices gibt es das nicht. Insb. nicht für Anfänger; und Administratoren sollten wissen was Mount-Points etc,. sind.
Klar, das ist für sich aber noch kein Grund, auf die anderen Vorteile zu verzichten.
Ein Inhaltsbasierte und Benutzungsorientiertes Finden von Dateien ist schon ok. Aber so einfach ist das auch wieder nicht, denn wie geht man mit Mehrdeutigkeiten um. Ja man kann das Lösen, aber kann der vielzitierte Anfänger das auch noch verstehen? Schon mal versucht sowas wie Heuristiken etc. einem Anfänger zu erklären? (ich schon).
Anfänger werden sich irgendwie durchschummeln. Auch jetzt schon legen angeblich viele Windowsbenutzer alle eigenen Dateien in den gleichnamigen Ordner, die können nur gewinnen. Je mehr Kenntnisse dann dazu kommen, desto besser können fortschrittliche Techniken gentzt werden, um Suchergebnisse zu verbessern.
Wenn man so was will, kann man es ja in Konquerer einbauen, mit nettem Klicke-di-Klick Interface. Aber ein Dateisystem soll zuverlässig, schnell und skalierbar sein und sonst nix. Der Rest ist eine Sache des Anzeigens der Information.
Tja, wenn's mal so einfach wäre. Natürlich kann ein Dateisystem nur so gut sein wie das Interface, und nur weil das von ext3 schon 30 Jahre als ist, ist keine Garantie für die Qualität. Was mir als Umsteiger von OS/2 zB. immer noch fehlt, sind erweiterte Attribute.
Ausser Anfängern gibt es ja auch noch professionelle Benutzer, die z.B. Software entwickeln. Die brauchen andere Tools. (Vergleiche die Bedieneranleitung und Bordwerkzeuge im Auto mit den Handbüchern und Werkzeugen in einer Autowerkstatt). Ich ziehe für diese Art von Aufgaben die Kommandozeile vor, denn das ist schneller und ___reproduzierbarer___ als mittels GUI.
Mach doch, was hat das mit dem Dateisystem zu tun? Thorsten -- "But beware of the dark side... If once you start down the dark path, forever will it dominate your destiny, consume you it will..." "...Is the dark side stronger?" "No...no...no. Quicker, easier, more seductive."
Thorsten Haude
Was mir als Umsteiger von OS/2 zB. immer noch fehlt, sind erweiterte Attribute.
Die du in Linux höchstwahrscheinlich nie finden wirst, da sie zu nichts anderem kompatibel sind. Über NFS könnten solche EAs nie übertragen werden und Tools wie tar, cpio und alle Dateipacker wie gzip, bzip2 etc. müssten wie seinerzeit für OS/2 speziell angepasst werden. EAs waren eine nette Idee, aber sie sind auch komplett inkompatibel zum Rest der Welt. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
*** Michael Gebhart (SuSELinux@MikeTech.net) schrieb in suse-linux am Dec...:
[...] [...]. Was haltet ihr von dem neuen Dateisystem, oder der Idee prinzipiell? Wäre so etwas nicht etwas revolutionäres, was sich auch Linux zu eigen machen könnte?
Wer sich den Vorreiter für diese "innovative" oder angeblich "revolutio- näre" Idee anschauen möchte: BeOS installieren. Dort ist praktisch genau das realisiert. Es gibt eine klassische FS-Schicht, die die Verzeichnisse und Dateien wie gewohnt darstellt, gleichzeitig kann man aber die Datenbank als genau eine solche Abfragen. Warum das nicht breiteren Einzug gehalten hat!? Im Vergleich zum Nutzen ist es offenbar und verständlicherweise Resourcenverschwendung. Aber defür interessiert sich Redmond ja bekanntlich nicht :-]. Wenn ich Daten nach verschiedenen Kriterien indizieren will/muß, verwen- de ich eben eine Datenbank. Ansonsten nehme ich es hin, dass ich mal ein "find" gepaart mit einem "file" laufen lassen muß... MfG Henning Hucke -- Ein Wunsch kann durch nichts mehr verlieren als dadurch, dass er in Erfuellung geht. -- Peter Bamm
On Sat, 7 Dec 2002, Michael Gebhart wrote:
Hi zusammen,
Hallo... ~snip~
Folgende Abfragen wären möglich: Liste alle Dokumente auf, die ich in den letzten 5 Tagen erstellt habe und auf die von den Programmen X, Y und Z zugriffen wurde.
Oder: Lege aus den Bildern vom 10-12.11.02, die von den Usern X und Y gesehen wurden eine Bildergalerie an.
das was Du da beschreibst ist ein Document Managemant System. Sowas gibts schon ne ganze Weile, nur das MS es wohl nicht im User-Mode sondern (zumindest teilw.) im Filesystem implementieren will. Vermutlich wird das Filesystem mit BTrees arbeiten (aehnlich ReiserFS) und nicht mit einer relationalen DB, weil das einfach unbrauchbar waere (obwohl, von denen ist man ja einiges gewohnt ;-)). Ausserdem werden die wohl einfach mehr Platz fuer Metadaten reserviert haben, z.B. welche Anwendung zu welcher Datei gehoert usw. IMHO kann XFS sowas aehnlich auch schon. Alles andere wird wohl auch in User-Mode laufen, weil das nicht ins Filesystem gehoert (z.B. Changelogs, Zwischenstaende von Dokumenten...)
Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend. Verzeichnisse verwirren Anfänger immer wieder. Wenn man so einfach alle Dateien sortiert und strukturiert, je
die Bedienung eines DMS ist auch nicht ohne... Ausserdem wird es sicherlich noch Laufwerke geben, sonst wuerden die alten Proggies ja nicht laufen. Die arbeiten dann natuerlich brav am DMS vorbei und damit isses fuer die Katz ;-) Trotzdem werden sich da einige DMS-Hersteller schon gewaltig in die Hosen machen, wenn MS in den markt einsteigt ;-)
nach Art der Abfrage aufgelistet bekommen würde, hätten die wenigstens Probleme einen PC zu bedienen. Was haltet ihr von dem neuen Dateisystem, oder der Idee prinzipiell? Wäre so etwas nicht etwas revolutionäres, was sich auch Linux zu eigen machen könnte?
gibts auch schon einiges OpenSource-maessiges... http://freshmeat.net/search/?q=Document+Management§ion=projects Im grunde ist selbst das CVS eine Art DMS fuer Source-Code...
Mike
cu. peter -- | LEISTRITZ Aktiengesellschaft Tel.: +49 (0) 911 4306 559 | Peter Woelfel, EDV-Abteilung Fax: +49 (0) 911 4306 478 | Markgrafenstrasse 29-39 eMail: pwoelfel@leistritz.de | D-90459 Nuernberg Web: http://www.leistritz.de
participants (18)
-
Achim Luft
-
Adalbert Michelic
-
B.Brodesser@t-online.de
-
Christoph Maurer
-
David Haller
-
Fritz Ganter
-
Heinz W. Pahlke
-
Henning Hucke
-
Jan.Trippler@t-online.de
-
Jürgen Vollmer
-
Manfred Tremmel
-
Matthias Houdek
-
Michael Gebhart
-
Michael Schulz
-
Mirko Richter
-
Peter Woelfel
-
Philipp Thomas
-
Thorsten Haude