Als ich zum ersten Mal im Leben mit Excel zu tun hatte, gab es 256 Spalten und 65.536 Zeilen. Bei meinem Erstkontakt mit OpenOffice Calc war ich erstaunt, dass die Spaltenbeschriftung nicht nur bis IV, sondern bis AMJ ging - macht satte 1024 Spalten. Nun setzt Libre Office noch einen drauf und glänzt daneben mit 1.024.576 Zeilen.
Halten wir uns nicht mit der Frage auf, wer das braucht - darum geht es mir nicht. Trotzdem frage ich mich: Was soll der Unsinn??
Meine Erfahrung: Sobald eine Datei bei ca. 150 Spalten - knapp 2/3 der Kapazität von Excel, gut 1/7 bei Open- und LibreOffice - auf eine fünfstellige Anzahl Zeilen kommt, kracht die Tabellenkalkulation gnadenlos zusammen. Excel meldet dann, "dass nicht genügend Ressourcen zur Verfügung stehen", OpenOffice friert einfach total ein oder schmiert ohne Vorwarnung ab. Wiederherstellung bleibt erfolglos.
Der Augenblick, in dem das passiert, ist entweder das Abspeichern der Datei oder der Versuch, eine Zeile mit Formeln per Doppelklick bis unten durchzuziehen.
Ich habe schon den Arbeitsspeicher von LibreOffice auf den Maximalwert von 256 MB gesetzt, die entstehenden Dateien haben bislang Maximalwerte von 36 MB erreicht - am Speicher kann es also nicht liegen. Bei mir zuhause werkelt eine 4-Kerne Intel Xeon CPU mit 2,8 GHz. Ist das immer noch zu wenig?
Mag ja sein, dass rund 2 Mio. Zellen mit mehr oder weniger komplexen Wenn-Formeln nicht in zwei, drei Sekunden berechnet werden können - nur wofür, wenn nicht dafür, ist eine Tabellenkalkulation sonst da? Und was soll ich mit über 1 Mio. Zeilen, wenn jede Office-Software, egal ob MS oder Open, schon bei 20.000 gnadenlos die Grätsche macht?
Ich kenne zumindest eine Person die sich über die Aufhebung der alten Excel-Grenzen gefreut hat.
Abgesehen davon sollte man da aber ernsthaft drüber nachdenken ob eine Tabellenkalkulation dann noch das richtige Werkzeug ist und nicht ganz vielleicht doch eher eine Desktop-Datenbank...
Dann bleibt aber immer noch die Frage, worin der Sinn der Grenzerweiterung besteht, wenn selbst die Ausnutzung auch nur eines Bruchteils(!) der alten(!) Grenzen das System bereits zum Zusammenbruch führt.
Bietet mir eine Desktop-Datenbank alle Möglichkeiten, die mir eine Tabellenkalkulation auch bietet, also sämtliche Formeln und Formatierungen, Fensterfixierungen, Verteilung von Daten über mehrere Tabellenblätter etc.?
Mit "Base" unter OpenOffice scheint es schon mal nicht zu gehen, die Datenbank ist eindimensional, nämlich nur vertikal. In der Horizontalen habe ich lediglich Feldname, Wert und Beschreibung - davon kann ich nichts gebrauchen. Ich brauche nur Zahlen, Zahlen und nochmal Zahlen, und ganz wichtig - die Datei muss in beiden Richtungen erweiterbar sein, sowohl horizontal als auch vertikal.
Bietet mir eine Desktop-Datenbank alle Möglichkeiten, die mir eine Tabellenkalkulation auch bietet
Nein, selbstverständlich nicht. Eine Datenbank hat ja eine ganz andere Philosophie wie eine Tabellenkalkulation.
Aber eine Datenbank kann eben sehr viel besser mit Millionen von Datensätzen (= Zeilen) umgehen; das war doch die Frage.
Wie man die Millionen Zeilen in Excel und Co sinnvoll nutzen soll, weiß ich auch nicht. Dennoch denke ich, dass die früher üblichen Grenzen (65.536 Zeilen x 256 Spalten) doch etwas eng waren. Und wenn diese Grenzen jetzt gefallen sind, kann das doch nur gut sein. Dann kann man auch mal 100.000 oder 150.000 Zeilen nutzen. Oder mal 500 Spalten - warum nicht. Die komplette Größe voll auszunutzen ist wohl (aktuell noch) eine Illusion.
Bietet mir eine Desktop-Datenbank alle Möglichkeiten, die mir eine Tabellenkalkulation auch bietet, also sämtliche Formeln und Formatierungen, Fensterfixierungen, Verteilung von Daten über mehrere Tabellenblätter etc.?
nein, natürlich nicht. Der Aufgabenbereich weiner Datenbank unterscheidet sich enorm von dem einer Tabellekalkulation
Mit "Base" unter OpenOffice scheint es schon mal nicht zu gehen, die Datenbank ist eindimensional, nämlich nur vertikal. In der Horizontalen habe ich lediglich Feldname, Wert und Beschreibung - davon kann ich nichts gebrauchen.
Diese Aussage versteh ich jetzt nicht ganz
Ich brauche nur Zahlen, Zahlen und nochmal Zahlen, und ganz wichtig - die Datei muss in beiden Richtungen erweiterbar sein, sowohl horizontal als auch vertikal.
Nein, muss nicht. Dass du das meinst liegt daran, dass du "flach" denkst - in den Strukturen einer Tabellenkalkulation.
Eine einzelne "Tabelle" einer DB arbeitet nunmal zeilenorientiert, die anzahl der Felder darin (="Spalten" in Excel) legt derjenige fest, der die Tabellen erstellt.
Daten werden in DB völlig anders organisiert, als in einerm Tabellenkalkulationssheet. Letzlich kann man aber durch verknüpfung mehrerer Tabellen untereinander danmn doch wieder dafür sorgen, dass alles so läuft, wie es soll.
Die Aussage ist wortwörtlich zu nehmen - ich brauche weder Feldnamen noch Beschreibung. Alles was ich brauche, sind eine Zeile oben, eine Spalte links, und sonst nur noch Formeln, Formeln, Formeln.
Dass du das meinst liegt daran, dass du "flach" denkst - in den Strukturen einer Tabellenkalkulation.
Etwas anderes als eine Tabellenkalkulation habe ich nie gewollt. Die Pseudo-Alternative "Datenbank" wurde nicht von mir ins Spiel gebracht - ich wollte mir nur erst einmal die Argumente dafür anhören und nicht in Bausch und Bogen alles ablehnen.
Weiß denn irgendjemand hier, was das für Ressourcen sind, die bei Excel zu knapp werden? Bei 256 MB RAM in den Programmeinstellungen gegenüber Dateigrößen unter 40 MB und mehreren Gigabyte Arbeitsspeicher kann das ja nicht das Problem sein.
Oder gibt es eine maximale Gesamtzahl an erlaubten Zellen, die keinesfalls überschritten werden darf?
Was aber, wenn es gar nicht um "Verwaltung" von irgendetwas geht, sondern um Berechnungen?
Und welchen Sinn hat es, die Kapazitäten einer Software weiter zu steigern, wenn bereits eine auch nur bruchteilweise Ausnutzung ihrer alten(!) Kapazität jedes beliebige System zum Krachen bringt, auch mit 8 GB RAM und 4 Kernen und 2,8 GHz?
Was aber, wenn es gar nicht um "Verwaltung" von irgendetwas geht, sondern um Berechnungen?
Man kann natürlich auch in einer Datenbank Berechnungen ausführen. Das wird nur ganz anders gemacht als in einer Tabellenkalkulation.
Und welchen Sinn hat es, die Kapazitäten einer Software weiter zu steigern, wenn bereits eine auch nur bruchteilweise Ausnutzung ihrer alten(!) Kapazität jedes beliebige System zum Krachen bringt
Das war zu der Zeit, als die früheren Grenzen festgelegt wurden schon genau so. Irgendwann waren die Rechner dann soweit, die Dimensionen auch auszureizen. Das Format ist also insofern ziemlich zukunftsorientiert. Noch zwei, drei Jahre, dann werden wir diese Rechner haben, denen dann auch Millionen von Zeilen keine Probleme mehr bereiten.
Ehrlich gesagt, nein... bei 2 GB RAM (Windows-Rechner) bzw. sogar 8 GB (Mac Pro) sollte eine max. 37 MB große Datei eigentlich keine Schmerzen verursachen.
Wie gesagt, mir scheint, das ist keine Frage von Speichergrößen - mir kommt es eher so vor, als wenn die CPUs mit der Komplexität der Wenn-Formeln nicht klarkommen. Immerhin sprechen wir hier von über 2 Mio. Zellen (150 Spalten x ca. 16.000 Zeilen). Nur, wie gesagt - selbst die älteste Excel-Version bietet noch weit mehr Spalten und Zeilen an, die Open-Geschichten sogar noch mehr.
Meine Erfahrung: Sobald eine Datei bei ca. 150 Spalten - knapp 2/3 der Kapazität von Excel, gut 1/7 bei Open- und LibreOffice - auf eine fünfstellige Anzahl Zeilen kommt, kracht die Tabellenkalkulation gnadenlos zusammen. Excel meldet dann, "dass nicht genügend Ressourcen zur Verfügung stehen", OpenOffice friert einfach total ein oder schmiert ohne Vorwarnung ab. Wiederherstellung bleibt erfolglos.
Ich habe beruflich schon mit angelieferten csv-Tabellen mit mehr als 120.000 Zeilen zu tun gehabt, die ich dann erst mal via Access um die nicht wirklich benötigten Zeilen kürzen musste, damit ich in Excel überhaupt erst Berechnungen anstellen konnte.
Später dann haben wir mit WinXP 64 Bit und Excel 2007 endlich die gesamte Tabelle öffnen können und - so nach Kollegenmeinung - uns die Zeit, die wir mit Access vergeuden, sparen.
Das war zwar korrekt - bis auf den Fakt, dass die Excel nun dadurch, dass es deutlich mehr Zeilen mit Formeln zu berechnen hatte, deutlich langsamer lief und es keine reelle Zeitersparnis gibt. (Es wurde wohl vergessen darauf zu achten, dass man in diesem Fall mutmaßlich auch mehr RAM und CPU-Power benötigt).
Soweit meine Erfahrung - aber ich muss jetzt die Fliege machen... vielleicht später mehr!
Später dann haben wir mit WinXP 64 Bit und Excel 2007 endlich die gesamte Tabelle öffnen können
Die Excel-Version ist von 2002 und läuft auf einem 32 Bit XP - daran könnte es liegen, dass es unter Windows nicht geht.
LibreOffice läuft unter Mac OS X 10.5.8 auf einem Mac Pro - hier dürfte es nicht an BS und Hardware liegen. Evtl. ist LibreOffice einfach "schwächer" als Excel, zumindest dass man mit einer aktuellen Excelversion unter einem 64-BIt-System mehr herausholen könnte.
Ich habe jetzt mal einen Open-Office-Größentest durchgeführt.
Auf meiner Kiste (Core2Dou 3GHz; 8 GByte RAM; Win7 64 Bit; MS Office 2007 H&S; OO 3.3) habe ich mit Excel eine Tabelle mit 300 Spalten und 120.000 Zeilen generiert (Inhalt jeder Zeile sind die Zahlen von 1 bis 300). Ich habe keine Formeln für den ersten Aufschlag verwendet.
Diese Tabelle habe ich dann ein mal als xlsx- und als csv-Datei gespeichert. (160 MByte und 128 MByte)
Geöffnet habe ich beide Tabelle in Excel 2007 "relativ flott". Das Öffnen hat keine gefühlte Minute gedauert. Excel hat bei der geöffneten Tabelle knappe 300 MByte RAM verlangt.
OO 3.3 ist beim Öffnen der xlsx-Datei abgestürzt.
Das Öffnen der csv-Datei hat funktioniert aber eine 3/4-Ewigkeit in Anspruch genommen. Schätzungsweise 4-5 Minuten. Habe leider keine Stoppuhr hier.
Dabei gönnte sich OO bei mir über an 1 GByte RAM.
Den Test mit einer einfachen Summierungsformel je Zeile habe ich mir jetzt gespart. Schon jetzt laufen die Werte zwischen den beiden Office-Paketen deutlich auseinander.
Fazit: OO hat deutlich Optimierungsbedarf bei größeren Tabellen. Wenn 700 MByte Mehrverbrauch an RAM gegenüber Excel 2007 finde ich schon beachtlich. Keine Ahnung, wieder Bedarf noch steigt, wenn ich nur die erste Spalte und Zeile mit Werten fülle und die restlichen Zellen mit einer einfachen Formel.... Schneller dürfte OO auf jeden Fall nicht werden. Und - so, wie es Du auch erlebt hast - würde ich mich über Abstürze nicht wundern.
Mit den MB-Zahlen habe ich mich übrigens getäuscht, auch meine Versuche sind zeitweise deutlich über 100 MB gekommen. In LibreOffice kann ich max. 256 MB Speicher vorgeben, sowohl für das ganze Programm als auch für ein einzelnes Objekt in diesem. Da ist also auch irgendwann Ende der Fahnenstange.
OO 3.3 würde ich jetzt einmal mit meinem LibreOffice gleichsetzen, aber dein Vergleich mit Excel 2007 ist in jedem Fall interessant. Deine Schlussfolgerung bzgl. Optimierungsbedarf bei den Open-Calcs scheint der richtige Ansatz zu sein. Eingefleischte Excel-Fans könnten bei dieser Gelegenheit auch sagen: Was nix kostet, taugt auch nix ;-)
zumindest dass man mit einer aktuellen Excelversion unter einem 64-BIt-System mehr herausholen könnte.
Das glaubst aber auch nur Du. Eher das Gegenteil ist der Fall.
1. Die 64-bit-Version von Office 2010 ist schwächer als die 32-bit-Version. 3D-Charts zum Beispiel gibt es nur in der 32-bit-Version. Mal abgesehen von der fehlenden Add-On-Unterstützung der zahlreichen Softwareschmieden.
2. Selbst die 32-bit-Version von Excel 2010 ist auf einem 9 Jahre alten Desktop-PC (XP, 256 MB RAM, Single-Core) schneller als auf meinem Notebook (HP Entertainment, Dual-Core, 4 GB RAM, Windows 7 64-bit, 2 Jahre alt), und zwar um ca. 19 Sekunden. Das Notebook braucht also 19 Sekunden länger als dieser alte Urgroßvater unter meinen verfügbaren PC's.
3D-Charts zum Beispiel gibt es nur in der 32-bit-Version. Mal abgesehen von der fehlenden Add-On-Unterstützung der zahlreichen Softwareschmieden.
Das mag sein, ist für meine Fragestellung aber nicht relevant. Hier geht es ja mehr um elemantare Funktionen, die im Grund sehr simpel sind, in der großen Masse aber mächtig Ressourcen zu fressen scheinen.
Selbst die 32-bit-Version von Excel 2010 ist auf einem 9 Jahre alten Desktop-PC (XP, 256 MB RAM, Single-Core) schneller als auf meinem Notebook
Wobei Geschwindigkeit gar nicht so das Problem ist. Ich wäre ja bereit zu warten, nur wenn die Software sich komplett aufhängt, hilft auch das nicht mehr.
mir kostet auch ein Kopfschütteln das man da nicht sagt "nimm eine Datenbank".
Aber wie es mir scheint wird dies öfters gebraucht als wie man denkt.
Letztens gab es in einer C't einen Test mit dem Microsoft HPC (Cluster) da wurde unter anderem auch mit Excel getestet.
Mit einem Cluster und mehreren Excel Instanzen könnte es sein das du die Milion erreichst :-)
mir kostet auch ein Kopfschütteln das man da nicht sagt "nimm eine Datenbank".
Es wurde aber doch vorgeschlagen, eine Datenbank zu nehmen? Das Problem ist eher, dass die Funktionalität, die ich benötige, nach einer Tabellenkalkulation schreit - spezielle Datenbankfunktionen benötige ich nicht, wohl aber die ganze Fülle der Formeln und Berechnungen.
Mit einem Cluster und mehreren Excel Instanzen könnte es sein das du die Milion erreichst :-)
Genau deswegen meine Frage: Wozu bietet die Tabellenkalkulatione bereits in einer Instanz alleine 1 Mio. Zeilen an, wenn ich nicht einmal 20.000 davon nutzen kann, ohne dass mir alles um die Ohren fliegt?
Du könntest mal das Orakel der Softwarehersteller fragen :-)
Apropos ist dies eine xls (bis 2003) Datei oder schon eine xlsx (ab 2007) Datei?
Sonst könnte es eine Einschränkung von Format Konverter sein. Wenn die Datei noch zu öffnen ist dann versuche diese im neuen Format zu speichern.
Sonst wäre ein Support-Call bei MS sicher ein Tipp.
Nee, das ist alles anno Tobak, die Excel-Version ist von 2002. Zuhause habe ich LibreOffice in der aktuellsten Version, allerdings ist mir schon öfter aufgefallen, dass die Tabellenkalkulation bei den Open-Produkten weit weniger leistungsfähig ist als Excel.
Das kann ich bestätigen, daß man bei ein paar Tausend Datensätzen schon an die Grenzen von Excel stoßen kann. Das Scrollen z. B. geht dann nur noch im Zeitlupentempo.
Ich denke mal, daß diese Kapazitäten nicht darauf ausgelegt sind, voll ausgeschöpft zu werden in der Dimension x * y.
Sondern daß die maximal mögliche Zeilenzahl bei vielleicht zwei Spalten gerade mal noch läuft - eben um Grenzbedingungen zu ermöglichen. Max. Anzahl Zeilen mal max. Anzahl Spalten ist also nur Theorie.
Man kann aber auch eine Datenbank wie Excel schnell zum Erlahmen bringen, wenn man eine Suche nicht nur über Schlüsselfelder, sondern als Volltextsuche durchführt - da kannst Du die Sanduhr rieseln sehen.
Ich denke mal, daß diese Kapazitäten nicht darauf ausgelegt sind, voll ausgeschöpft zu werden in der Dimension x * y.
Das Problem - zumindest bei Excel 2007 - ist, dass es nicht mehr als 2 GByte Speicher belegen kann. Es ist halt eine 32Bit-Anwendung.
Ich habe zwischenzeitlich eine Tabelle (Größe wie oben) mit einer Formel angelegt:
Zeile 1: Die Werte 1 bis 300 eingetragen (Spaltenüberschrift)
Spalte A: Die Werte 1 - 120000 eingetragen (Zeilenbezeichnung)
In dieser Matrix habe ich dann die einfache Formel "=[Spaltenüberschrift]*[Zeilenbezeichnung]" eingetragen und in alle Zellen kopiert.
Im Taskmanager konnte ich dann sehen, wie Excel ganz schnell an die 2 GByte-Grenze stieß und mit einem Fehler "Zu wenig Ressourcen" die Operation abbrach.
Wenn ich jetzt davon ausgehe, dass Calc wie oben festgestellt mehr Ressourcen braucht wie Excel wunderst mich Olafs Ergebnis inzwischen keinesfalls.
Abhilfe würde meiner Einschätzung nach eine reine 64-Bit-Office-Anwendung schaffen.
Im Augenblick würde mir nur dazu einfallen, die Berechnungsmatrix auf mehrere Tabellen ggf. sogar auf mehrere Dateien aufzuteilen.
Nur wie kommen diese 2 GB zustande, wenn die Datei beim Abspeichern weit weniger als 1 GB belegt? Oder sind das zwei verschiedene Paar Schuhe, d.h. kann die Datei zwischenzeitlich beim Bearbeiten mehr Speicher in Anspruch nehmen als sie schlussendlich auf der Festplatte belegt?
Die Idee mit der Verteilung auf mehrere Dateien zu verteilen ist mir inzwischen auch gekommen - das wäre noch einmal einen Versuch wert.
Nur wie kommen diese 2 GB zustande, wenn die Datei beim Abspeichern weit weniger als 1 GB belegt?
Zum Abspeichern der Datei mit den Formeln bin ich gar nicht gekommen :o)
Grundsätzlich gibt es ja das Problem, dass Anwendungen unter Win 32 Bit nicht mehr als 2 GByte RAM nutzen (adressieren?) können. Ich habe mit X³ Terran Conflict ein Spiel was gerade daran "krankt". Allerdings hat Egosoft es hinbekommen, dass diese 32 Bit-Anwendung unter 64-Bit Windows mehr als 2 GByte nutzen kann.
Abgesehen davon dürften knapp 36 Millionen Formeln in einer Tabelle (300 x 120.000 abzüglich erste Zeile/Spalte) schon kein Pappenstil sein und zur Berechnung durchaus mehr RAM benötigen als reine Werte in einer Zelle.
Vielleicht sollte man solch umfangreiche Berechnungen via Script erledigen, so dass in den Zellen das Endergebnis, aber nicht die Formel landet. Das dürfte effizienter sein. Kennt sich hier jemand mit Scripten aus?
Nur wie kommen diese 2 GB zustande, wenn die Datei beim Abspeichern weit weniger als 1 GB belegt
ODF und XLSX/XLSM/XLSB (und all die anderen OOo/LibreOffice- Dateien und Microsoft Open XML-Dateien) sind nur gepackt so klein.
Bei diesen Dateitypen handelt es sich um ZIP-kompatible Dateiformate. Entpackt man die Dateien, dann sind sie mindestens genau
so groß wie eine XLS-Datei, meisten sogar noch größer (einfach mal eine Datei mit Winzip
oder Winrar in einen Ordner entpacken und dann die Größe anschauen). Und genau das passiert
beim Öffnen der Dateien, sie werden temporär entpackt. Sind die Dateien zu groß, dann läuft der Speicher über oder die Berechnungen dauern zu lange.
Danke euch beiden - ich denke, das erklärt einiges.
Wobei meine OO/LO-Dateien im Vergleich zu den XLSsen immer genau so groß waren, nämlich zwischen 35 und 100 MB, je nach Komplexität und "Wachstumsstadium" (die Datei ist eigentlich auf ein weiteres Anwachsen ausgelegt).
Was mir noch aufgefallen ist, speziell @mchawk: Eine 32-Bit-Anwendung müsste doch ca. 3,5 GB Speicher adressieren können und nicht nur 2 GB?
Kurz: Ein 32-Bit-Prozess kann normalerweise nur 2 GByte adressieren. Ein 64-Bit-Prozess bis zu 8 TByte.
Das ganze kenne ich halt vom http://forum.egosoft.com , bei dem das halt in Bezug auf das Spiel immer wieder diskutiert wurde.
In der Tat hatte Egosoft mit deutlichen Stabilitätsproblemen zu kämpfen, als sie es ermöglichen wollten in einer 64-Bit-Umgebung dem 32-Bit-Prozess mehr RAM zu verschaffen.
Inzwischen scheint es recht stabil zu laufen.
Ich gehe mal davon aus, dass Office diese "IMAGE_FILE_LARGE_ADDRESS_AWARE"-Geschichte einfach nicht anwenden kann, will und tut.
Kurz: Ein 32-Bit-Prozess kann normalerweise nur 2 GByte adressieren.
Das lese ich heute zum ersten Mal. Rein rechnerisch komme ich auf 4 GB, abzüglich etwas "Verwaltungsoverhead", also realistischerweise nur 3,5 statt 4.
Genaueres weiß ich auch nicht - und diese Einschränkung betrifft halt Windows. Über die Situation bei Linux/Mac sagt das natürlich nichts aus.
Es kann natürlich sein, dass diese Grenze von Microsoft einfach willkürlich gesetzt wurde. Vielleicht damit Windows selbst und die Hintergrundtasks nicht in RAM-Not kommen? Nix Genaues weiß ich nicht.
MS hat ja auch die 3,5 GByte-Grenze bezüglich des RAMS willkürlich gesetzt - Es gibt ja schon Techniken, mit denen sich auch unter 32 Bit mehr als 4 GByte RAM nutzen ließen.
Nein, da ist gar nichts willkürlich! Wenn du nachrechnest, wie viele Speicherzellen man mit 32 Bit adressieren kann, dann kommst du unweigerlich auf 4 GB. Abzüglich Verwaltungsoverhead sind dann ca. 3,5 GB für die Praxis verfügbar. Damit hat Microsoft nichts zu tun.
Deswegen meine Verwunderung über die anscheinende "Drosselung" auf 2 GB bei Office-Programmen.
an kann aber auch eine Datenbank wie Excel schnell zum Erlahmen bringen,
Wieso Excel? Da sollte wohl eher Access stehen, Excel ist keine DB
wenn man eine Suche nicht nur über Schlüsselfelder, sondern als Volltextsuche durchführt
nur gibt es keine "Volltextsuche" in Access. Eher dürftest du einen "Full table scan" meinen; und ja, der kann auch das schnellste System buchstäblich zur Schnecke machen ..
Wieso Excel? Da sollte wohl eher Access stehen, Excel ist keine DB
Richtig - ich meinte Access.
nur gibt es keine "Volltextsuche" in Access. Eher dürftest du einen "Full table scan" meinen; und ja, der kann auch das schnellste System buchstäblich zur Schnecke machen ..
Falsch - als Volltextsuche wird das Suchen nicht nur in den Indexfeldern, sondern über alle Felder der Datenbank bezeichnet. Diese gibt es in Access und ich benutze sie jeden Tag.
Ob Du das Ding jetzt "Full Table Scan" nennen willst, ich nenne das Ding Volltextsuche, weil wir hier in Deutschland sind und ich das Deutsch noch nicht völlig verlernt bzw. durch Anglizismen ersetzt habe. Ist aber mit Sicherheit dasselbe, vorausgesetzt, wir reden von einer Suche nach Text. Für Zahlen und andere Feldinhalte gibt es sicherlich andere Funktionen. Aber ich habe in meiner Datenbank nur Text und Telefonnummern, die ich als Textformat definiert habe, weil sonst die führende Null unterschlagen wird.
Würde ich noch selbst programmieren, würde ich wahrscheinlich auch die Funktionsnamen gebrauchen. Aber ich bin "nur noch" Anwender, versuche, mit geringstmöglichem Aufwand mein Ziel zu erreichen.
Ist zwar Leichenfledderei, aber FullTableScans und Volltextsuche sind zwei vollkommen unterschiedliche Dinge.
Ein FullTableScan bedeutet, dass jeder Datensatz der Tabelle einmal angeschaut werden muss weil kein zur Abfrage passender Index vorhanden ist um den Suchraum einzuschränken. Das kann passieren, wenn nach Feldwerten gesucht wird ohne, dass ein Index auf diesem Feld existiert, oder aber wenn nach Feldwerten gesucht die nicht am Anfang eines Indexes stehen, oder aber nicht nach Präfixen der Indizierten Felder.
WHERE fieldname LIKE "prefix%" -- kann durch einen Index bedient werden,
WHERE fieldname LIKE "%notprefix%" -- kann nicht durch einen Index bedient werden.
Die zweite Variante kann man allerdings durch eine Volltextsuche unter Einsatz einer speziellen Volltext-Indizierung ohne die Notwendigkeit eines FullTableScans lösen.
Ich denke mal, daß diese Kapazitäten nicht darauf ausgelegt sind, voll ausgeschöpft zu werden in der Dimension x * y.
Ja, so etwas habe ich auch schon gedacht. Wobei es dann aber um so komischer wirkt, wenn die Ausbreitung in beiden Dimensionen - 1024 statt 256 Spalten und 1 Mio. statt 65536 Zeilen - als Fortschritt gefeiert wird. Da würde ich eher tendieren zu sagen: Kriegt doch erstmal die Probleme in den Griff, die ihr mit den alten "Abmessungen" habt ;-)
Eine Suchfunktion benötige ich aber nicht, insofern ist es egal, ob die schnell oder lahm arbeitet.
kann es sein dass die hohen Arbeitsspeicherwerte nur bei OOo unter Windows auftreten? Ich kann das hier auf ubuntu 10.04 mit LibreOffice zumindest nicht nachvollziehen, habe auf einem einfach Büro-PC mit Intel P4 und 3 GHz sowie 2GB RAM das mal getestet, über 300 MB verbraucht LibreOffice nicht, dauert allerdings ne ganze Weile bis die Tabelle geladen ist.
Ein Excel unter WinXP (Office 2003) benötigt auf der selben Maschine allerdings gefühlt etwas weniger Zeit.
Zum Glück brauche ich solche Monstertabellen nie! ;-)
kann es sein dass die hohen Arbeitsspeicherwerte nur bei OOo unter Windows auftreten?
Das ist selbstverständlich im Bereich des Möglichen. Ich konnte es halt nicht testen, da ich Linux zur Zeit nur auf meinem Router und NAS-Server laufen habe.
habe auf einem einfach Büro-PC mit Intel P4 und 3 GHz sowie 2GB RAM das mal getestet, über 300 MB verbraucht LibreOffice nich
Das ist auch ungefähr der Wert, den ich unter Windows mit Excel 2007 hatte.
Allerdings habe ich - wie oben beschrieben - sieht das mit ca. 36 Millionen Formeln deutlich anders aus.
(Es ging ja darum, dass man Ausgangswerte in der ersten Spalte und ersten Zeile hat und der Rest berechnet werden soll.)
Da wäre es sicherlich mal interessant, ob es unter Linux z. B. auch eine 2 GByte-Grenze gibt - aber für diesen Test wird Deine Maschine wohl etwas mehr RAM benötigen.
in Excel unter WinXP (Office 2003) benötigt auf der selben Maschine allerdings gefühlt etwas weniger Zeit.
So eine Monstertabelle unter XP mit Office 2003? Hm... XP 64 Bit?
Ansonsten habe ich so meine Zweifel, ob Du wirklich von einer Monstertabelle sprichst. ;)
ich hätte da gleich 2 Themen, weshalb man sich über die neuen Kapazitäten freuen darf:
1. Datenmigrationen: stell Dir vor Du möchtest Daten aus einem Altsystem in ein neues System (sagen wir irgendein custom-build Altsystem und ein neues SAP System) bringen.
Das Altsystem besitzt aber keine Schnittstellen o.ä., ist aber immerhin in der Lage, Daten als .csv Dateien zu exportieren. Wenn Du so eine Datei dann noch überarbeiten möchtest vor dem Import ins SAP, bist Du sehr glücklich wenn die noch ins Excel passt :-).
2. SAP Business Explorer Analyzer Plugin für Excel (kurz "BEx Analyzer"). Ermöglicht eine Direktverbindung von SAP BI und Excel und ist neben (mittlerweile beliebterem Webzugriff über SAP Portal) quasi der Standard zur Auswertung von SAP BI Daten.
Für "klassische" Aufgaben sehe ich die alten Limits tatsächlich nicht sehr kritisch - die beiden o.g. Themen sind in der Praxis allerdings wirklich interessant, dh hier bringt die Änderung wirklich Benefit.
Hi Basskilla, keines deiner beiden Themen beantwortet meine Überlegungen auch nur ansatzweise.
Um es einmal mit einem dieser beliebten Autovergleiche zu sagen: Du hast eine Kiste mit 120 PS und sollst damit 180 km/h schaffen können - tatsächlich aber fliegt dir bereits bei Tempo 130 der Motor um die Ohren.
Jetzt kommt der Auto-Tuner deines Vertrauens und verkündet dir freudestrahlend, mit einem Motorupgrade auf 190 PS könntest du in Zukunft 300 km/h schaffen.
Wärst du da wirklich so begeistert, mit Blick auf die o.g. Erfahrung?
nee, natürlich beantwortet mein Posting nicht die Frage wegen der genannten Performanceproblematik.
Deine Frage im Titel war aber "wem nützt das eigentlich" - und meine beiden Beispiele wären dazu eine mögliche Antwort. Hier wird Excel eben nicht klassisch als Tabellenkalkulation verwendet, sondern eher zum Datacleansing etc (und da ist diese Problematik nicht so entscheidend, da man da idR keine großen Berechnungen macht). Da sind die 190 PS schon hilfreich :-)
Performanceprobleme bei der Berechnung von umfangreichen Formeln konnte ich übrigens auch schon feststellen - vor Allem wenn irgendwelche Formatierungen vorhanden sind. Mit CSV Daten kommt man hier immerhin schon ein gutes Stück weiter.
Formatieren in Excel mache ich nur noch in kleinen Tabellen. Meist nutze ich für die Formatierung Word, ziehe dann die Daten mit Serienbrieffunktion rüber.
...inzwischen ist es mir gelungen, die Formeln drastisch zu vereinfachen - es kommen inzwischen überhaupt keine Wenn-Abfragen mehr vor. Die Dateigröße konnte ich damit zunächst von ca. 36 auf etwas über 28 MB reduzieren.
Dann habe ich an der Datei weitergestrickt - zuletzt nur noch in der Horizontalen, nicht mehr in der Vertikalen. Jetzt bin ich insgesamt bei rund 23.000 Zeilen und knapp 1000 Spalten. Die Datei hat sich dadurch zwar fast auf 55 MB verdoppelt und lädt entsprechend lahm - stürzt aber nicht mehr ab!
Ich nehme daraus die Erkenntnis mit, dass die Problematik weniger eine Frage der absoluten Dateigröße, als der Komplexität der eingesetzten Formeln ist. Wenn die Datei sich "einen Wolf rechnen muss", stürzt die Tabellenkalkulation anscheinend leichter ab.
Borlander
Olaf19
mawe2
neanderix
mchawk
mumpel1
Wiesner
rotthoris
basskilla
