Holla, für die Zusammenarbeit mit Kollegen innerhalb der Abteilung soll eine Art "Mini-Datenbank" aufgesetzt werden. Bisher gibt es dafür eine Excel-Tabelle, die aber an ihre Grenzen stößt (hätte z.B. gern eine dritte Dimension). Als Beispiel nenne ich jetzt einfach mal Produkt, Markteinführungsdatum. Jetzt gibt es das Produkt aber noch unter verschiedenen Labels, deren Markteinführungszeitpunkte verschieden sind. Sowas kann ich in Excel zwar mit mehreren Zeilen und SVERWEISen irgendwie hinwürgen, aber sauber ist anders und spätestens falls ich irgendwann mal nicht mehr in der Firma bin kennt sich kein Mensch mehr aus. Ich habe mir schon bisschen überlegt, was alternativ zum Einsatz kommen könnte und würde gern eine kleine GUI mit Python aufsetzen. Das traue ich mir zu, bisschen programmieren kann ich und der Rest wird halt nach Bedarf gelernt :). Nur, die Daten müssen irgendwo hin und sollen nichtflüchtig gespeichert werden (nur RAM während der Ausführung des Skripts geht also auf keinen Fall). Von Datenbanken habe ich bisher nicht wirklich Ahnung. Was bietet sich denn da für den Einstieg an? Mit abgebrannten Grüßen Pleitegeier
pleitegeier schrieb: > falls ich > irgendwann mal nicht mehr in der Firma bin kennt sich kein Mensch mehr > aus. Und wie denkst du dies Problem mit Python zu loesen ? Gibt es keine kommerziel verfuegbare software ? Oder mach eine beschreibung fuer die Excel file Patrick aus die Niederlaende
pleitegeier schrieb: > Was bietet sich > denn da für den Einstieg an? SQLite . Die selbe !!! Datenbank kann ich unter Android, Visual-(Basic // C ) und was weiß ich noch nutzen. Und eine Schnittstelle zu irgend einer Server-DB sollte auch nicht das Problem sein. Wenn man die DB mit einen SQL-Manager (gibts für Lau) anlegt und die Indexe macht, sollte es nicht wirklich schwer sein, die Zugriffe und Abfragen mal eben mit einen eigenen Programm zu machen. Übernahme der Daten via EXCEL / CSV ist auch nix weltbewegendes. Wäre jedenfalls mein Vorschlag. Und DU bekommst SQLite-Datenbanken NICHT an ihre Grenzen was die Datenmenge angeht. ;) Meine größte hat aktuell ca. 12 Mio. Datensätze.
pleitegeier schrieb: > Ich habe mir schon bisschen überlegt, was alternativ zum Einsatz kommen > könnte und würde gern eine kleine GUI mit Python aufsetzen. Das traue > ich mir zu, bisschen programmieren kann ich und der Rest wird halt nach > Bedarf gelernt :). > Nur, die Daten müssen irgendwo hin und sollen nichtflüchtig gespeichert > werden (nur RAM während der Ausführung des Skripts geht also auf keinen > Fall). > Von Datenbanken habe ich bisher nicht wirklich Ahnung. Was bietet sich > denn da für den Einstieg an? Da gibt es eine fast unüberschaubare Vielzahl an Möglichkeiten, von der klassischen (meist SQL-)Datenbank wie PostgreSQL über vollindizierte, verteilte Systeme wie OpenSearch (dem Namen zum Trotz sehr viel mehr als eine Volltextsuchmaschine) NoSQL-Systeme wie MongoDB oder Cassandra, bis hin zu Spezialisten wie Zeitseriendatenbanken oder Key-Value-Stores wie Redis, der In-Memory arbeitet (mit feingranular konfigurierbaren Backups) und deswegen extrem performant ist. Du hast schon sehr gut daran getan, rudimentär zu beschreiben, wie die Daten aussehen, aber leider fehlen trotzdem noch einige Angaben. Die eine ist, was Du mit den Daten machen willst: einfach nur anschauen, statistische Auswertungen oder Prognosen mit Verfahren des Machine Learning? Die nächste offene Frage ist, wie auf die Daten zugegriffen werden soll, und zwar insbesondere geschrieben. Sobald parallele Zugriffe ins Spiel kommen, fallen bestimmte Systeme wie SQLite (von dem ich auch aus anderen Gründen abrate, das ist lediglich etwas für ganz besondere Anwendungsfälle) aus der Wahl. Und die dritte offene Frage ist, wie schmerzhaft partielle Datenverluste, -inkonsistenzen und / oder eine fehlende Verfügbarkeit sind... Stichwort Brewers Theorem oder CAP-Theorem. Was Deine Python-GUI angeht, so ist das eine Möglichkeit, aber je nachdem, wie viele Leute am Ende mit Deiner GUI arbeiten und welche Rechte sie bekommen sollen, könnte es eine bessere Idee sein, eine kleine Webanwendung zu entwickeln, etwa mit Flask oder Django. Die kann dann wahlweise zentral gehostet, oder auf die Rechner der Mirarbeiter deployt und lokal ausgeführt werden -- so machen es die Entwickler von PgAdmin4 als Nachfolger ihres FatClient PgAdmin3 (das sind Administrationstools für die äußerst leistungsfähige und flexible SQL-Datenbank PostgreSQL).
Patrick C. schrieb: > pleitegeier schrieb: >> falls ich >> irgendwann mal nicht mehr in der Firma bin kennt sich kein Mensch mehr >> aus. > Und wie denkst du dies Problem mit Python zu loesen ? Python ist eine zwar sehr leistungsfähige, dennoch aber besonders einfache Sprache, die außerdem das Konzept der Docstrings integriert. Mit diesen Docstrings kann man eine Menge machen, zum Beispiel auch einfache Unittests, die dann gleichzeitig die Nutzung der Klasse oder Funktion dokumentieren, und der Clou ist: auf Docstrings kann man aus dem laufenden Programm heraus zugreifen.
pleitegeier schrieb: > Was bietet sich > denn da für den Einstieg an? Auch wenn ich mich jetzt wahrscheinlich unbeliebt mache: Access. Wenn es "beinahe" mit Excel funktioniert, ist das ein relativ einfacher Schritt, und wenn ihr in der Abteilung keine festen "Tooling"-Zuständigkeiten habt, ist das noch am wenistens schlecht in Bezug auf Zukunftssicherheit. (Hättet ihr "Tooling"-Zuständigkeiten, würde die Frage wohl nicht im Forum auftauchen.)
Walter T. schrieb: > Auch wenn ich mich jetzt wahrscheinlich unbeliebt mache: Access. Also bei mir machst Du Dich nicht unbeliebt, aber es hängt natürlich davon ab, wie die Daten genutzt und geschrieben werden sollen. Wenn mehrere Leute gleichzeitig auf aktuelle Daten zugreifen oder gar dort schreiben wollen, braucht Access wieder ein "richtiges" Backend wie PostgreSQL oder ein anderes SQL-RDBMS. Sonst hast Du sehr bald achtundpfirsich verschiedene Datenbanken, die mit widersprüchlichen Inhalten auf den Festplatten von drölf Kollegen herumoxydieren, und dann kannst Du schauen, wie Du die wieder eingefangen und zusammengeführt bekommst -- wenn überhaupt.
Schlaumaier schrieb: > pleitegeier schrieb: >> Was bietet sich >> denn da für den Einstieg an? > > SQLite . Die selbe !!! Datenbank kann ich unter Android, Visual-(Basic > // C ) und was weiß ich noch nutzen. Hier wäre vielen Fragenden sicherlich besser geholfen, wenn Du ihnen nicht ständig mit diesem Spielzeug kommen würdest. Denn SQLite ist durchaus ein nettes Spielzeug, aber eben auch nicht mehr. Es unterstützt die SQL-Standards nur teilweise, und ist vor allem nicht typsicher. Das schränkt einerseits seine Kompatibilität und damit auch seine Migrationsfähigkeit mit echten SQL-Datenbanken massiv ein, und kann auf der anderen Seite für inkonsistente Daten sorgen, was dann meist einen teilweisen, womöglich sogar kompletten Datenverlust zur Folge haben kann.
Ein T. schrieb: > Wenn > mehrere Leute gleichzeitig auf aktuelle Daten zugreifen oder gar dort > schreiben wollen ... > [...] > "richtiges" Backend wie > PostgreSQL oder ein anderes SQL-RDBMS Sicher. Oder eine Basis auf Sharepoint oder active Directory oder ähnliches. Aber: Dann gibt es auch üblicherweise irgendeinen IT- oder Tooling-Verantwortlichen oder gar -Abteilung. Der oben beschriebene Anwendungsfall sieht für mich nach Access-Datenbank auf Netzlaufwerk als Ersatz für Excel-Datei auf Netzlaufwerk aus, wo die rudimentären Locking-Mechanismen noch ausreichen.
:
Bearbeitet durch User
Walter T. schrieb: > Der oben beschriebene Anwendungsfall sieht für mich nach > Access-Datenbank auf Netzlaufwerk als Ersatz für Excel-Datei auf > Netzlaufwerk aus, wo die rudimentären Locking-Mechanismen noch > ausreichen. Möglich, oder eben auch nicht, und deswegen ja auch meine Nachfragen. Ohne diese Fragen geklärt zu haben, insbesondere die nach der beabsichtigten Nutzung und den gewünschten Zugriffsmöglichkeiten (insbesondere vor dem Hintergrund der Aktualität der Daten und eventuellen parallelen Schreibzugriffen) läßt sich leider kaum eine seriöse Empfehlung abgeben. Im Zweifel wäre meine Empfehlung aber ein "richtiger" Datenbankserver wie PostgreSQL und ein Webfrontend etwa in Python, damit läßt sich sicherlich die größtmögliche Bandbreite aller denkbaren Anwendungsfälle abdecken. Nebenbei bemerkt kann PostgreSQL auch ODBC und JDBC sprechen, womit auch eine mögliche Nutzung der Daten durch Microsoft Office-Produkte und Java-Anwendungen gewährleistet wäre. Gleichzeitig bieten alle mit bekannten Programmiersprachen Schnittstellen zu PostgreSQL, so daß die Daten auch für Analysen, Auswertungen, Visualisierungen und womöglich sogar Anwendungen des Machine und Deep Learning genutzt werden könnten, in Python etwa mit numpy, Pandas, scikit, statsmodels, sklearn, Tensorflow, Keras, ...you get the idea. Gerade Python, nach dem der TO gefragt hatte, ist ja im Umgang mit Daten extrem leistungsfähig und vielfältig. Insofern halte ich es für sinnvoll, zuerst die aktuellen und möglichen zukünftigen Anwendungsfälle abzufragen, bevor eine wie auch immer geartete Empfehlung gegeben wird. Sonst legt der Fragende sich im Zweifelsfall von vorneherein auf etwas fest, das seine Flexibilität hinsichtlich der Nutzung der Daten einschränkt. Dann gibt es zwei Möglichkeiten: entweder er bemerkt, daß seine ursprüngliche Wahl nicht ideal gewesen ist und kann sich dann einen großen Teil der Arbeit nochmal machen (und / oder sich gegebenenfalls sogar einen Anpfiff "das hätten Sie doch wissen müssen" abholen), oder er bemerkt es nicht einmal und kommt deswegen nicht auf sinnvolle Ideen, was er mit seinen Daten noch alles an klugen Dingen anstellen könnte.
Interesannt: So ein langer Dialog über Datenbank mit GUI und niemand kommt auf die Idee, Filemaker Pro auch nur zu erwähnen. Es gibt m.W. definitv keine andere Software am Markt (ist nicht kostenlos), bei der die integrierte Entwicklung von Datebank (Tabellen mit Beziehungen) und der dazugehörigen GUI mit allen nur denkbaren Layouts und Bedienlementen (inkl. Bild- und Dokumenten-Container, Webviewer usw.) sowie eine differenzierte Rechte-verwaltung so einfach wäre. Inklusive responsive Design für Mobilgeräte. Ist das FM-Projekt mit der Client-Software (Windows und Mac) fertig entwickelt, kann man es im Netz mit "Filemaker Server" (Windows, Mac, Linux) publizieren. Wenn man sich im Layout an etwas eingeschränkte Regeln hält, kann man das FM-Projekt auch mit "Filemaker Direct" als Webanwendung publizieren. Dann genügt als Client ein Browser ... Nachtrag: Filemaker Server hat auch eine ODBC/JDBC-Schnittstelle, so dass fremde Tools an den Daten "andocken" können. Ebenso kann ein FM-Projekt Tabellen aus anderen Datenbanken (z.B. MySQL, MariaDB) einbinden ...
:
Bearbeitet durch User
Wie andere auch schon geschrieben haben. Wenn aktuell Excel verwendet wird ist Access als Ersatz ja eine naheliegende Lösung.
Weiterer Nachtrag: Die Kenntnis der Grundlagen des Datenmodellentwurfes, wie die Normalformen, die Regeln bezüglich primary key und foreign keys, referenzieller Integrität usw., die bleiben einem natürlich auch beim Einsatz von Filemaker nicht erspart.
Beitrag #7155060 wurde von einem Moderator gelöscht.
pleitegeier schrieb: > für die Zusammenarbeit mit Kollegen innerhalb der Abteilung soll eine > Art "Mini-Datenbank" aufgesetzt werden. Was tauscht ihr denn da genau aus bzw. wie sieht das ganze aus? PLant ihr da Arbeitsabläufe? Schau Dir mal EdrawMax (https://www.edrawsoft.com/de) an das kann u.a. auch datenbankbasierte Flowcharts/Organigramme. Das Programm ist zwar nicht kostenfrei ist dafür aber recht vielfältig einsetzbar. Eine einzelne Lizens für 229,-€ bzw. eine Zweierlizenz für 286€ finde ich angesichts des Funktionsumfanges fair. Zudem ist das Programm für Win, Mac, Linux und als Webapplikation verfügbar.
Frank E. schrieb: > Interesannt: So ein langer Dialog über Datenbank mit GUI und niemand > kommt auf die Idee, Filemaker Pro auch nur zu erwähnen. Ich kann das nicht beurteilen, aber viele kennen Filemaker nicht einmal und von denen, die davon gehört oder es sogar benutzt haben, höre ich oft Zweifel an der Zukunftsfähigkeit -- das allerdings schon seit sehr vielen Jahren, weswegen ich mittlerweile meinerseits an der Substanz solcher Aussagen zweifle. ;-) Aaaber mein Punkt ist: da hat jemand eine womöglich fundamentale Änderung vor, sagt aber leider nur wenig zu seinem konkreten Anwendungsfall und leider auch nicht viel dazu, was zukünftig gewünscht werden könnte. Ich habe schon mehrmals erlebt, daß der Umstieg einer kleinen Unternehmensanwendung von Excel auf eine zentrale Datenbank zu vielen oftmals sehr klugen Ideen geführt hat, was man mit den Daten sonst noch alles machen, welche Daten man noch in die Datenbank verlagern, und wie man diese dann mit den anderen Daten verknüpfen könnte. Irgendwie habe ich in diesem Thread das vage Gefühl, daß hier zwar niemand so genau das Problem des TO kennt, aber jeder schon (s)eine Lösung kennt. Fast wie in "ich habe eine Lösung und jetzt brauche ich nur noch ein passendes Problem". ;-)
Zeno schrieb: > pleitegeier schrieb: >> für die Zusammenarbeit mit Kollegen innerhalb der Abteilung soll eine >> Art "Mini-Datenbank" aufgesetzt werden. > > Was tauscht ihr denn da genau aus bzw. wie sieht das ganze aus? PLant > ihr da Arbeitsabläufe? Richtig und wichtig! Das Wichtigste bei der Software/Datenbankentwicklung ist das Prozess- und Datenmodell und ein (agiles) Konzept zur Realisierung. Das kostet heute ca. 80% der Aufwendungen, das eigentliche Coden ist fast schon Nebensache. "Agil" bedeutet, dass man flexibel bleibt, in regelmäßigen (rel. kurzen) Abständen prüft, ob das im Werden begriffene Projekt noch den aktuellen Ansprüchen genügt, ansonsten muss man gegensteuern. Früher kam es oft vor, dass eine mühsam geplante Entwicklung im Moment der Fertigstellung bereits schon wieder veraltet war oder sich die Ansprüche der Nutzer geändert hatten.
Frank E. schrieb: > Die Kenntnis der Grundlagen des Datenmodellentwurfes, wie die > Normalformen, die Regeln bezüglich primary key und foreign keys, > referenzieller Integrität usw., die bleiben einem natürlich auch beim > Einsatz von Filemaker nicht erspart. Es gibt Dokumentdatenbanken, die häufig weder eine Normalisierung und manchmal nicht einmal einen Datenbankentwurf erfordern. Deswegen ist ja mein Reden, daß wir erst einmal den TO bezüglich seines genauen Anwendungsfalls anhören sollten, bevor wir ihn mit Lösungen bombardieren, die mal bei uns in unseren, womöglich aber gänzlich anderen Anwendungsfällen funktioniert haben.
Ein T. schrieb: > Frank E. schrieb: >> Interesannt: So ein langer Dialog über Datenbank mit GUI und niemand >> kommt auf die Idee, Filemaker Pro auch nur zu erwähnen. > > Ich kann das nicht beurteilen, aber viele kennen Filemaker nicht einmal > und von denen, die davon gehört oder es sogar benutzt haben, höre ich > oft Zweifel an der Zukunftsfähigkeit -- das allerdings schon seit sehr > vielen Jahren, weswegen ich mittlerweile meinerseits an der Substanz > solcher Aussagen zweifle. ;-) Ja, die Diskussionen kenn ich. Totgesagte leben länger. Wir machen sehr viel mit Filemaker, z.B. vom ERP-System (Auftragsabwicklung und Rechnungslegung) mit fast 200 Tabellen, einer wissenschaftlichen Artikelverwaltung für ein Museum (mit Webanbindung) bis hin zu einer App fürs iPhone, um Rolläden zu steuern. Letzteres hat zwar nix mit Datenbank zu tun, aber es war schnell und einfach gemacht, dank der zur Verfügung stehenden Befehle. > Aaaber mein Punkt ist: da hat jemand eine womöglich fundamentale > Änderung vor, sagt aber leider nur wenig zu seinem konkreten > Anwendungsfall und leider auch nicht viel dazu, was zukünftig gewünscht > werden könnte. Vorbereitung ist Alles, keine Frage. Ein kluges modulares Konzept gestattet nahezu beliebige Erweiterbarkeit. Setzt aber Profis voraus, zumindest zur Beratung in der Anfangsphase. Manchmal hilft auch schon das Lesen eines geeigneten Fachbuches. > Ich habe schon mehrmals erlebt, daß der Umstieg einer > kleinen Unternehmensanwendung von Excel auf eine zentrale Datenbank zu > vielen oftmals sehr klugen Ideen geführt hat, was man mit den Daten > sonst noch alles machen, welche Daten man noch in die Datenbank > verlagern, und wie man diese dann mit den anderen Daten verknüpfen > könnte. Der Effekt ist bekannt: "Der Appetit kommt beim Essen". Gründliche Vorbereitung statt wildem Drauf-Los-Hacken reduziert Überraschungen. Und systematisches Arbeiten: Die nächste Option kommt erst, wenn die vorherige sauber läuft. > Irgendwie habe ich in diesem Thread das vage Gefühl, daß hier zwar > niemand so genau das Problem des TO kennt, aber jeder schon (s)eine > Lösung kennt. Fast wie in "ich habe eine Lösung und jetzt brauche ich > nur noch ein passendes Problem". ;-)
Ein T. schrieb: > Frank E. schrieb: >> Die Kenntnis der Grundlagen des Datenmodellentwurfes, wie die >> Normalformen, die Regeln bezüglich primary key und foreign keys, >> referenzieller Integrität usw., die bleiben einem natürlich auch beim >> Einsatz von Filemaker nicht erspart. > > Es gibt Dokumentdatenbanken, die häufig weder eine Normalisierung und > manchmal nicht einmal einen Datenbankentwurf erfordern. Deswegen ist ja > mein Reden, daß wir erst einmal den TO bezüglich seines genauen > Anwendungsfalls anhören sollten, bevor wir ihn mit Lösungen > bombardieren, die mal bei uns in unseren, womöglich aber gänzlich > anderen Anwendungsfällen funktioniert haben. Du meist die NoSQL-Ecke und die Ideen aus BigData. Welches Konzept da besser geeignet ist, hängt tatsächlich von der Art der Daten ab. Google könnte aufgrund der Unterschiedlichkeit der zu indizierenden Objekte tatsächlich mit SQL garnix anfangen, ähnlich liegt das bei Dokumentenverwaltungen (z.B. EcoDMS, kenn ich). Aber in Verwaktungen von Firmen geht es meist um immer gleiche und dafür sehr viele Strukturen und Prozesse (Personal, Artikel, Aufträge), da ist bis heute nix besser als die relationale Datenbank geeignet.
Frank E. schrieb: > Ja, die Diskussionen kenn ich. Totgesagte leben länger. Wie gesagt, ich kann das nicht beurteilen und deswegen (leider?) nur wiedergeben, was ich im Wald raunen höre. > Wir machen sehr viel mit Filemaker, z.B. vom ERP-System > (Auftragsabwicklung und Rechnungslegung) mit fast 200 Tabellen, einer > wissenschaftlichen Artikelverwaltung für ein Museum (mit Webanbindung) > bis hin zu einer App fürs iPhone, um Rolläden zu steuern. Letzteres hat > zwar nix mit Datenbank zu tun, aber es war schnell und einfach gemacht, > dank der zur Verfügung stehenden Befehle. Hört sich jedenfalls cool an, wobei... wissenschaftliche Artikel sind doch sicher Textdokumente, oder? In solchen Fällen hätte ich über ein System nachgedacht, das eine Volltextsuche beherrscht, und ich kenne keine einzige SQL-Datenbank, die das wirklich kann. Ja, ja, die meisten bieten da irgendwelche Features, tsvector etwa bei PostgreSQL, FULLTEXT in MySQL und wie sie alle heißen. Die Funktionen sind da und liefern auch Ergebnisse, aber die sind miserabel. Ein anständiges, womöglich sogar konfigurierbares Scoring wie in einer... "richtigen" Volltext-Suchmaschine, beispielsweise OpenSearch, Elasticsearch, oder Apache Solr, können sie alle nicht. Eine fehlertolerante Suche, die auch Tippfehler findet, etwa mit der Levenshtein- oder Hamming-Distanz, können die klassischen Datenbanken leider ebenfalls nicht. Hinzu kommt, daß Textdokumente häufig ganz unterschiedliche Strukturen haben, das kann ein starres RDBMS nicht wirklich gut abbilden. Die obengenannten Volltext-Suchmaschinen arbeiten mit variablen Strukturen, mithin: Dokumenten, und können deshalb viel besser mit strukturellen Unterschieden umgeben. Naja, ich kenne Euren Auftrag ja nicht und deswegen auch nicht den konkreten Anwendungsfall, und bitte, versteh' mich nicht falsch, ich möchte Dir und Deinen Kollegen unter keinen Umständen etwas unterstellen. Aber trotzdem möchte ich mir meinen vorsichtigen Hinweis erlauben, daß 95% der mir bekannten Entwickler beim Thema "Daten speichern" geradezu reflexartig ausschließlich SQL-Datenbanksysteme nennen. Sogar die zumindest mal gehört haben, daß es da noch was anderes gibt. Das ist ein klassischer Fall des Hammerproblems: sie kennen halt nichts anderes, und selbst wenn sie mal davon gehört haben, bleibt das weitgehend abstrakt. Und wenn dann noch über CAP geredet wird und daß die NoSQL-Datenbanksysteme meist (zu denen auch OpenSearch, Elasticsearch und Solr gehören) nicht dieselben Garantien bieten (können) wie klassische SQL-RDBMS, ... ;-) > Der Effekt ist bekannt: "Der Appetit kommt beim Essen". Gründliche > Vorbereitung statt wildem Drauf-Los-Hacken reduziert Überraschungen. Und > systematisches Arbeiten: Die nächste Option kommt erst, wenn die > vorherige sauber läuft. Najaaa... mit einer SQL-Datenbank begibt man sich ja wieder in starre Strukturen, und das ist der Grund für Deine absolut richtigen Hinweise hier und weiter oben. Natürlich: für bestimmte Daten will, nein: braucht man diese starren Strukturen, deswegen benutzt man dafür ein RDBMS. Aber bei anderen Daten sind solche starren Strukturen eher hinderlich, und wenn man dann ein System verwendet, das besser zum Anwendungsfall paßt, entfallen oft auch viele Notwendigkeiten für genaue Planung, sauberes Changemanagement und vieles andere, auf das Du hingewiesen hast. Wenn ich mein Datenmodell jederzeit dynamisch erweitern kann, und obendrein nicht mit fixen Relationen arbeiten muß, vereinfacht das viele Dinge ganz erheblich. Wie gesagt: laßt uns doch erstmal den TO anhören, was er genau machen möchte, und dann können wir ihm eine sinnvolle Lösung empfehlen. Leider hat er sich bisher nicht mehr gemeldet, aber vielleicht tut er das ja noch.
Frank E. schrieb: > Aber in Verwaktungen von Firmen geht es meist um immer gleiche und dafür > sehr viele Strukturen und Prozesse (Personal, Artikel, Aufträge), da ist > bis heute nix besser als die relationale Datenbank geeignet. Für streng strukturierte Daten ist das sicherlich korrekt, und ich bin der Letzte, der für solche Daten etwas anderes als ein RDBMS empfehlen wollte. Andererseits liegen in vielen Unternehmen auch schwach und nicht strukturierte Daten vor, denk nur an Verträge, Dokumentationen und andere Publikationen, und die in ein RDBMS zu pressen, ist aufwändig und in vielerlei Hinsicht teuer. Da sind andere Lösungen oft viel effizienter und viel weniger aufwändig.
Zeno schrieb: > Schau Dir mal EdrawMax (https://www.edrawsoft.com/de) an das kann u.a. > auch datenbankbasierte Flowcharts/Organigramme. Das Programm ist zwar > nicht kostenfrei ist dafür aber recht vielfältig einsetzbar. Bitte entschuldige, aber hier war eine Datenspeicherlösung gefragt, und Du empfiehlst stattdessen eine -- obendrein kostenpflichtige -- Software zur Visualisierung? Zumal hier auch Python erwähnt wurde, das viele sehr mächtige Frameworks zur Visualisierung bietet -- und dazu noch so vieles mehr.
Leute es geht um ein besseres Hobby-Projekt. Da reicht Sqlite völlig aus. Klor hat das Einschränkungen aber wayne juckt es. Access ist eine alternative Lösung aber sehr Stress behaftet. Und der TO will da selbst eine GUI vor bastelt. Das bedeutet man legt die Datenbank mit einen Manager an, und schreibt ne kleine GUI für die Abfragen und die Reportdateien die man braucht. So was mache in unter VB in ca. 2-3 Tagen je nach Aufwand. Wichtig ist nur eins. Das er über die Datenbank NACHDENKT. Und sich die Struktur sehr sorgfältig überlegt. Ich habe schon dutzende 1 x Programme geschrieben die nix anders gemacht haben als eine Datenbank nur zu Strukturieren weil die alte Struktur von vorne bis hinter verwusselter Mist war. Und selbst bei einer Adressdatenbank kann man viel Mist bauen. Standart-Fehler PLZ + ORT in EIN Feld. Dazu muss man immer 3 (drei) Felder nehmen. Länderkennung - PLZ - ORT. Allein für diesen Fehler zu korrigieren musste ich schon ca. 15 Prg. schreiben in mein Leben schreiben. Und das nur weil Leute Programme nehmen die kein Schwein kennt. Kann sich noch jemand an TexAS erinnern. Der Hass + Grussel meiner frühen Programmierzeit.
Schlaumaier schrieb: > Access ist eine alternative Lösung aber sehr Stress behaftet. Und der TO > will da selbst eine GUI vor bastelt. Das geht mit Access am einfachsten und es ist ein "Bürostandard" vermutlich schon auf den Rechnern drauf. Kein geistig gesunder Mensch fummelt da mit SQLite im Büro herum.
Schlaumaier schrieb: > Leute es geht um ein besseres Hobby-Projekt. Es geht immerhin um ein Projekt mit Unternehmensdaten, in einem Unternehmen. Schon rein aus Definitions-, aber auch aus ganz praktischen Gründen hat das nichts mehr mit irgendwelchen Hobbies zu tun. > Da reicht Sqlite völlig aus. Klor hat das Einschränkungen aber wayne > juckt es. Jeden, der seriös arbeiten will. Okay, nach Deinen Einlassungen in diesem und etlichen anderen Threads habe ich den Eindruck, daß Dich das nicht betrifft. > Access ist eine alternative Lösung aber sehr Stress behaftet. Und der TO > will da selbst eine GUI vor bastelt. Das kommt darauf an, wie man Access benutzt. Als Frontend für ein richtiges RDBMS kann man das nehmen, aber mit der eingebauten Flatfile-Datenbank... naja. > Ich habe schon dutzende 1 x Programme geschrieben die nix anders gemacht > haben als eine Datenbank nur zu Strukturieren weil die alte Struktur von > vorne bis hinter verwusselter Mist war. Du hast Dein Datenmodell also schon dutzende Male verkackt? > Standart-Fehler PLZ + ORT in EIN Feld. Dazu muss man immer 3 (drei) > Felder nehmen. Länderkennung - PLZ - ORT. > > Allein für diesen Fehler zu korrigieren musste ich schon ca. 15 Prg. > schreiben in mein Leben schreiben. Ein kluger Entwickler hätte sich eine entsprechende Bibliothek herausgesucht oder selbst eine geschrieben, wenn er keine adäquate gefunden hätte. > Und das nur weil Leute Programme nehmen die kein Schwein kennt. Genau, Python kennt kein Schwein.
Hi, wir haben bei uns im Hause Atlassian Confluence und im Zusammenhang mit dem Insight Plugin einen Ersatz für eine Excel Inventarliste erstellt. Sicherlich nicht perfekt, aber durchaus für mehrere Wartbar und einfache Standard-Abfragen sind aus dem Wiki Modus recht einfach bedienbar. Reine Interne Datenbankprojekte haben den Nachteil, dass sie entweder irgendwann keiner mehr warten kann/will oder sich Fehler im Datenbank Design sehr mühsam später beheben lassen. Etwas problematisch wird es wenn man sich hierdurch eine Schatten-IT aufbaut. ZB wenn die Daten aus SAP exportiert werden um die woanders „besser“ zu verarbeiten, als stattdessen den Realen Workflow sinnvoll abzubilden.
Riesenschwengel schrieb: > Kein geistig gesunder Mensch fummelt da mit SQLite im Büro herum. Man fummelt auch nicht im Büro herum. Für so was ist die IT-Abteilung zuständig. Und die schon ihr Etat und nimmt SQLite wenn sie nicht gerade eh ne Datenbank am Start hat, wo man die Spielerei anhängt. ABER ich schätze den TO so ein, das die Firma entweder keine eigenen IT hat, und die IT auf OUTSOURCING hat, und er deshalb sich was zusammen frickeln will, um sich die Arbeit zu erleichtern. Ein T. schrieb: > Ein kluger Entwickler hätte sich eine entsprechende Bibliothek > herausgesucht oder selbst eine geschrieben, wenn er keine adäquate > gefunden hätte. Du musst erst mal so lange in der Branche sein wie ich. Es gab nämlich mal eine Zeit wo Bibliothek das war wo man hin ging wenn man ein Buch lesen wollte. Und die hatten mit IT rein gar nix zu tun. Dann kamen die ersten Datenbanken auf den Markt und DBASE machte damit ein Vermögen. Und dann fingen die Leute wie heute mit Access an, sich selbst Datenbanken anzulegen. Sie tippten fleißig Daten ein, und merkten dann, das sie 1000ende Datensätze hatten die kaum zu analysieren und abzufragen waren/sind. Und DANN kommen Leute wie ich ins Spiel. Die dieser Daten analysieren und dann vernünftig strukturieren. Und ich habe schon HAND-Daten-Adresssätze gehabt, die PLZ + ORT nicht getrennt haben. Allerdings aus der Vor-Smartphone-Zeit. Und die Software wurde von hochbezahlten Schwätzern wie dir die nur ne Bibliothek mit mühe einbinden können geschrieben.
Schlaumaier schrieb: > Ein T. schrieb: >> Ein kluger Entwickler hätte sich eine entsprechende Bibliothek >> herausgesucht oder selbst eine geschrieben, wenn er keine adäquate >> gefunden hätte. > > Du musst erst mal so lange in der Branche sein wie ich. Bin ich. Aber im Gegensatz zu Dir bin ich kein Stümper. > Und die Software wurde von > hochbezahlten Schwätzern wie dir die nur ne Bibliothek mit mühe > einbinden können geschrieben. Sich für eine sich wiederholte Aufgabe keine Bibliothek zu suchen ODER ZU SCHREIBEN ist ebenso unprofessionell wie Dein dummes Geschwafel über Datenhaltung.
Ein T. schrieb: > und ist vor allem nicht typsicher. Das hat mich auch schnell genervt an SQLite und verwende es deshalb auch nicht mehr. > Das schränkt einerseits seine Kompatibilität und damit auch seine > Migrationsfähigkeit mit echten SQL-Datenbanken massiv ein, Genau auf das Problem bin ich damit mehrfach gestossen. SQL und Kompatibilität ist ja eh ein Witz aber SQLite setzt da nochmal deutlich einen drauf.
pleitegeier schrieb: > Als Beispiel nenne ich jetzt einfach mal Produkt, Markteinführungsdatum. > Jetzt gibt es das Produkt aber noch unter verschiedenen Labels, deren > Markteinführungszeitpunkte verschieden sind. Das klingt für mich nach - einem PLM / CRM - einer NoSQL Anwendung, wenn du die "Labels" nicht wirklich benennen kannst respektive diese über alle Produkte und Produktgruppen nicht gleich sind. Einfach mal so am Rande: Wenn eure Firma / Team nicht die SW-Lösung vertreiben möchte, würde ich in den allermeisten Fällen auf eine Kauflösung oder Opensource gehen. Weil sonst hast du 100 Tools im Betrieb, die je nach Anwendung mit anderen Systemen kommunizieren müssen/sollten und ihr werdet wegen Betreuung, Updates, internen Schulungen von solchen Tools nur bei Tagesgeschäft ausgebremst. pleitegeier schrieb: > für die Zusammenarbeit mit Kollegen innerhalb der Abteilung soll eine > Art "Mini-Datenbank" aufgesetzt werden. Ich würde als aller Erstes einmal "Zusammenarbeit" genauer definieren. Was wollt ihr effektiv machen und wer ist alles Beteilig (welche anderen Teams, weil bei "Produkten" äusserst selten ein einzelnes Team arbeitet und koordiniert werden muss)? Und erst dann über das Tool entscheiden. - Projektmanagement - Kundenverwaltung - Produktdaten anhängen und verwalten - Marketing Koordination - Team übergreifend - ...
:
Bearbeitet durch User
pleitegeier schrieb: > Von Datenbanken habe ich bisher nicht wirklich Ahnung. Was bietet sich > denn da für den Einstieg an? Versuchs mal mit MySQL oder PostgreSQL ... es muß ja nicht immer Excel sein :-)
Robert K. schrieb: > pleitegeier schrieb: >> Von Datenbanken habe ich bisher nicht wirklich Ahnung. Was bietet sich >> denn da für den Einstieg an? > Versuchs mal mit MySQL oder PostgreSQL ... es muß ja nicht immer Excel > sein :-) Es muß auch nicht immer eine SQL-Datenbank sein.
@Threadstarter: Da Python ja offenbar eh die bevorzugte Programmiersprache wäre, würde ich mal "Django" anschauen. https://docs.djangoproject.com/en/4.1/ Mit Django kann man sehr leicht und schnell eine Datenbank-Anwendung mit web-basierter GUI in Python programmieren. In einfachen Fällen genügt es, ein paar "models" zu definieren (jedes Model entspricht im Grunde einer Tabelle einer relationalen Datenbank - im model legt man fest, welche Spalten die Tabelle hat) und das war's im Grunde auch schon. In der mitgelieferten Benutzerverwaltung noch schnell für jeden Benutzer einen Account anlegen und dessen Berechtigungen festlegen, fertig. Per default werden die Daten in einer automatisch angelegten sqlite-Datenbank gespeichert, weil das für den Einstieg am einfachsten und schnellsten geht - sobald dann alles läuft und man die Daten lieber einer besseren Datenbank speichern will, kann man dann leicht auf postgresql, MariaDB oder was auch immer wechseln. Am besten einfach mal das Tutorial anschauen. Eventuell gleich mit Teil 2 beginnen, denn in den anderen beiden Teilen geht es zum grossen Teil um "views" (vereinfacht gesagt: aus den Daten in der Datenbank beliebige html-Seiten erzeugen), die man für eine einfache Datenbankanwendung evtl. gar nicht benötigt, weil die automatisch erzeugte Admin-Oberfläche ausreichend ist: https://docs.djangoproject.com/en/4.1/intro/tutorial02/
Horst Horstson schrieb: > Mit Django kann man sehr leicht und schnell eine Datenbank-Anwendung mit > web-basierter GUI in Python programmieren. Oder mit Flask, oder mit Bottle.py, oder mit... you name it. Bisher sind wir aber noch nicht einmal sicher, ob eine Webapplikation mit einem klassischen SQL-RDBMS überhaupt die beste Wahl ist und nicht womöglich eher eine NoSQL-Datenbank besser geeignet sein könnte. Da der TO sich seit geraumer Zeit nicht mehr gemeldet hat, füchte ich auch, daß wir es nicht mehr erfahren werden.
> Sowas kann ich in Excel zwar mit mehreren Zeilen und SVERWEISen > irgendwie hinwürgen, aber sauber ist anders und spätestens falls ich > irgendwann mal nicht mehr in der Firma bin kennt sich kein Mensch mehr > aus. Dafür ist Excel in vielen Firmen nun mal die höchste Evolutionsstufe der Digitalisierung. Wenn dir wichtig ist, dass auch die Nachwelt was damit machen kann, bleib dabei :-D
Das Beste für Excel-Nutzer ist immer noch Access. Man kann aus Excel relativ zielführend die Tabellen und Zusammenhänge per COPY und PASTE einfügen und das auch so gestalten, dass die Links / Schlüssel-Indizes eindeutig anlegbar sind. Auch das manuelle Arbeiten in den Tabellen ist wie in Excel. Hat man das erst mal in Access kann man es mit ->"Datenzugriffsseiten" versehen, die sich jeder auf den Rechner kopieren kann, um zentral drauf zuzugreifen. Das Datenmanagement übernimmt Access, wenn man auf die "Sperrung auf Datensatzebene" nutzt. Und die alten Excelformulare kann man auch wieder erstellen lassen, wenn man Ausdrucke in der alten Version benötigt. Die Datenbank auf Access kann dann über ODBC / SQL zugegriffen und manipuliert werden, wenn man möchte. Ich habe zwischen 1995 und 2005 etliche solcher Excel-Systeme in Firmen umgestellt.
:
Bearbeitet durch User
Hm. Wer in zwei Monaten noch keine Design-Entscheidung getroffen hat, für den ist das Thema auch nicht wichtig.
Jürgen S. schrieb: > zwischen 1995 und 2005 Ja, wenn das damals gut war, ist das heute sicherlich auch noch so. Oliver
1N 4. schrieb: > Dafür ist Excel in vielen Firmen nun mal die höchste Evolutionsstufe der > Digitalisierung. Wenn dir wichtig ist, dass auch die Nachwelt was damit > machen kann, bleib dabei :-D Es ist schon einige Jahre her, da war ich in einer Firma die für irgendeinen Iso Standard für Verwaltung zertifiziert wurde welches ein Kunde forderte und in der Vorbereitung mussten wir von Excel weg,weil "Das Auftrags und Qualitätsmanagement in Excel wäre nicht mehr Zeitgemäß". Das ganze wurde dann von einer frei Konfigurierbaren Freeware (ERP) ersetzt.
TotoMitHarry schrieb: > Das ganze wurde dann von einer frei Konfigurierbaren Freeware (ERP) > ersetzt. Das lustige ist: selbst in Firmen, die schon seit vielen Jahren ein "richtiges" ERP einsetzen, gibt es in aller Regel viele Office-basierte Teillösungen (die dann aber im Idealfall wenigstens auf die DB des ERP-Systems entweder direkt oder über ein API des ERP-Systems zugreifen). Das liegt schlicht daran, dass die ERP-Systeme von Hause aus längst nicht so flexibel und unversell sind, wie die jeweiligen Hersteller gern suggerieren... Und das Schaffen einer echten Integration der Spezialaufgaben auf dem offiziellen Weg sind in aller Regel "unglaublich" teuer. Unglaublich steht deshalb in Anführungszeichen, weil es nur für Laien wirklich unglaublich ist. Tatsächlich entstehen diese Kosten bei dem Anbieter wohl tatsächlich. Schließlich hat erstens i.d.R. ein riesiger Moloch von viel zu gut bezahlten (aber technisch völlig nutzlosen) Wasserköpfen damit zu tun, bis es überhaupt zur Auftragserteilung kommt und zweitens muss dann, wenn es endlich ans Eingemachte geht, auch noch der Programmierer erstmal soweit über den Prozess beim Anwender des Zielsystems aufgeschlaut werden, dass er das Problem begreift, was er umsetzen soll. Angesichts dieser Tatsachen prophezeie ich den Office-basierten (Teil-)Lösungen noch eine unüberschaubar lange Zukunft. ERP-System hin oder her...
Datenbank und GUI mit Python. Warum hat noch niemand Qt bzw. pyside6 vorgeschlagen? https://doc.qt.io/qtforpython/examples/example_sql__books.html In die Qt einarbeiten lohnt sich immer. Und bei den SqlWidgets kann man das Datenbanksystem auch nach der Entwicklung noch ändern. Außerdem - alle zeitkritischen Sachen hat die Qt in C++ implementiert. Selbst mit einem schnell zusammen gekloppten Python Programm kann kann man ohne Verzögerungen durch tausende von Datensätzen scrollen.
c-hater schrieb: > Das lustige ist: selbst in Firmen, die schon seit vielen Jahren ein > "richtiges" ERP einsetzen, gibt es in aller Regel viele Office-basierte > Teillösungen (die dann aber im Idealfall wenigstens auf die DB des > ERP-Systems entweder direkt oder über ein API des ERP-Systems > zugreifen). > > Das liegt schlicht daran, dass die ERP-Systeme von Hause aus längst > nicht so flexibel und unversell sind, wie die jeweiligen Hersteller gern > suggerieren... Das Problem haben wir auch in meiner Firma. Auch die vorherige, bei der ich vor ihrer Insolvenz arbeitete. Beide waren / sind mittlere Betriebe (ca. 500 MA) der Fleich- und Wurstwarenindustrie und arbeiten mit dem gleichen Warenwirtschaftssystem (CSB). Auch da mußten öfter Excel & co. für spezielle Aufgaben her halten. Das Anpassen durch die Softwarefirma wäre da zu teuer gewesen.
:
Bearbeitet durch User
Heinz B. schrieb: > > Das Problem haben wir auch in meiner Firma. Auch die vorherige, bei > der ich vor ihrer Insolvenz arbeitete. Beide waren / sind mittlere > Betriebe (ca. 500 MA) der Fleich- und Wurstwarenindustrie und arbeiten > mit dem gleichen Warenwirtschaftssystem (CSB). Auch da mußten öfter > Excel & co. für spezielle Aufgaben her halten. Das Anpassen durch die > Softwarefirma wäre da zu teuer gewesen. Es gibt aber auch Software-Anbieter, die das besser lösen: Z.B. die deutsche Firma Pragma mit ihrem Druckerei-ERP "Chroma" (mit einer Oracle-DB im Hintergrund). Dieses ERP verfügt über eine eingebaute Python-Schnittstelle, so dass Kunden bestimmte Erweiterungen der GUI, der funktionalen Abläufe incl. Datenbankzugriffe selbst erledigen können - sofern sie wissen, was sie tun. Man bekommt sogar Starthilfe vom Hersteller, muss vorher aber eine Vereinbarung unterschreiben, dass bei nachweisbaren Schäden an der Datenbank keine Haftung übernommen wird.
Datenbankabfragen per SQL macht unser Systemadministrator auch. Wir Fahrer bekommen da jeden Monat auch Umsatzlisten gedruckt. Welcher Kunde einer bestimmten Tour wieviel Umsatz letzten Monat im Vergleich zum Vorjahresmonat gemacht hat. Auch Renner-Penner- Listen, also Artikel, die gut oder schlecht verkauft wurden, werden da ab und an gedruckt. Auch Ausdrucke von der Buchhaltung über offene Posten der einzelnen Kunden gibt es monatlich. Insofern ist das CSB - System schon variabel, sodaß man an manchen Schräubchen noch selber drehen kann. Aber halt für Spezielles, z.B. einen Chart muß dann wohl Excel herhalten.
In den letzten 40 Jahren hat sich nichts verändert. Mein erster Job war Daten vom Mainframe auf Novell-Fileserver kopieren. Die andere Abteilung hat dann für die Anwender Auswertungen in Lotus 1-2-3 geschrieben. Na ja, ein Punkt hat sich geändert. Excel gab es damals noch nicht.
Oliver S. schrieb: > Jürgen S. schrieb: > Ja, wenn das damals gut war, ist das heute sicherlich auch noch so. Richtig. Für die, die noch mit Excel arbeiten, um z.B. ihre Messergebnisse aus Laboren zu protokollieren, sie auszuwerten und mit Formularen anderer Firmen klarkommen müssen, ist das auch heute noch so. Access erfordert diesbezüglich nicht viel Einarbeitung der Excelnutzer.
sqlite ist klein aber nur fuer lokale files. mariadb is das neue mysql (server+client)aber recht bloated. es gibt mehr implementierungen (wikipedia hat eine liste) <https://en.wikipedia.org/wiki/List_of_relational_database_management_systems>; google "SQL third normal form".
Als Datenbank zu dem Warenwirtschaftsystem CSB nutzt meine Firma immer noch das PostgreSQL. Und vorschreiben, welches System CSB oder ERP und DB, kann man seinem AG ja nicht. Da muß man mit dem arbeiten, was vorhanden ist.
:
Bearbeitet durch User
Heinz B. schrieb: > Als Datenbank zu dem Warenwirtschaftsystem CSB nutzt meine Firma immer > noch das PostgreSQL. > > Und vorschreiben, welches System CSB oder ERP und DB, kann man seinem > AG ja nicht. Da muß man mit dem arbeiten, was vorhanden ist. Was spricht denn gegen PostgreSQL? Wir wollen gerade dahin migrieren...
Jan K. schrieb: > Was spricht denn gegen PostgreSQL? Wir wollen gerade dahin migrieren... Nichts, ist ausgereift und oft im Einsatz. merciless
Dirk K. schrieb: > Jan K. schrieb: >> Was spricht denn gegen PostgreSQL? Wir wollen gerade dahin migrieren... > > Nichts, ist ausgereift und oft im Einsatz. Kann ich nur bestätigen. Absolut stabile und performante Datenbank.
Frank M. schrieb: > Dirk K. schrieb: >> Jan K. schrieb: >>> Was spricht denn gegen PostgreSQL? Wir wollen gerade dahin migrieren... >> >> Nichts, ist ausgereift und oft im Einsatz. > > Kann ich nur bestätigen. Absolut stabile und performante Datenbank. Jepp, da würde ich mich anschließen. Die Datenbank selber ist wirklich sehr gut. Mit Sicherheit eine der besten RDBMS, die es überhaupt gibt. Ich mochte sie schon immer. Ich würde höchstens die Umstellung des Admin-GUI auf "Web-Technologien" anmosern (war aber auch schon vor einigen Jahren). Das hat den Spaß an der DB für Admins doch einigermaßen versaut. Doch schon sehr träge im Vergleich zu dem füheren nativen GUI. Aber wenigstens geschah die Umstellung ohne nennenswerten Verlust an Features (zumindest aus meiner Sicht).
Jan K. schrieb: > Was spricht denn gegen PostgreSQL? Wir wollen gerade dahin migrieren... Für Anwendungsfälle, für die ein relationales Datenbank-Managementsystem ideal ist: nichts. PostgreSQL ist ein extrem leistungsfähiges, flexibles und performantes System, das obendrein etliche interessante Erweiterungen unterstützt, zum Beispiel für Geodaten (PostGIS) und für Zeitseriendaten (TimescaleDB). Mit ein bisschen Fachkenntnis kann PostgreSQL außerdem sehr große Datenmengen verwalten, meine bisher größte PostgreSQL-Datenbank hat eine Größe von über sechs Terabyte, und ein Ende ist nicht in Sicht. Viel Spaß und Erfolg damit!
C-hater schrieb: > Ich würde höchstens die Umstellung des Admin-GUI auf "Web-Technologien" > anmosern (war aber auch schon vor einigen Jahren). Das hat den Spaß an > der DB für Admins doch einigermaßen versaut. Doch schon sehr träge im > Vergleich zu dem füheren nativen GUI. Aber wenigstens geschah die > Umstellung ohne nennenswerten Verlust an Features (zumindest aus meiner > Sicht). Gerade diese Umstellung ist für viele Admins wie mich ein Träumchen, weil ich dadurch viel flexibler bin und alles zentral pflegen kann. Und es ist auch nicht träger als der vorherige Fatclient -- jedenfalls nicht, wenn clientseitig ein halbwegs brauchbarer Rechner vorhanden ist. Mit Deinem Pentium2/300 hat auch Pgadmin3 keinen Spaß gemacht.
Sheeva P. schrieb: > Gerade diese Umstellung ist für viele Admins wie mich ein Träumchen, > weil ich dadurch viel flexibler bin und alles zentral pflegen kann. Hmm... Ich konnte das auch mit PgAdmin3 schon. Kann diesbezüglich keinen Vorteil erkennen. > Und > es ist auch nicht träger als der vorherige Fatclient Doch natürlich, darüber braucht man überhaupt nicht zu diskutieren. Bestenfalls fällt es nur nicht sehr auf, weil der Client schnell genug ist, um die ganzen Blähungen der Software doch noch schnell genug zu bearbeiten, damit es halt nicht auffällt... Ein langsamer Client zeigt halt schlicht und für jeden merklich die Wahrheit auf (und damit die Tatsache dass du hier schlicht lügst). So einfach ist das...
C-hater schrieb: > Sheeva P. schrieb: > >> Gerade diese Umstellung ist für viele Admins wie mich ein Träumchen, >> weil ich dadurch viel flexibler bin und alles zentral pflegen kann. > > Hmm... Ich konnte das auch mit PgAdmin3 schon. Kann diesbezüglich keinen > Vorteil erkennen. Und über VNC oder so war das dann schneller als Pgadmin4? Janeeisklaa. >> Und >> es ist auch nicht träger als der vorherige Fatclient > > Doch natürlich, darüber braucht man überhaupt nicht zu diskutieren. Ich hab' mit beidem gearbeitet, und die Unterschiede sind marginal -- bei manchen Dingen war Pgadmin3 schneller, bei anderen ist es Pgadmin4. Zudem verstehe ich nicht, warum Du über etwas diskutierst, über das es doch nach Deiner Aussage "überhaupt nicht zu diskutieren" gibt. > So einfach ist das... Ja, für Dich ist immer alles ganz einfach: alle doof außer Du.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.