4. Einfaches Client/Server-System à la SAP?

Einfaches Client/Server-System à la SAP?

  • F

    Mit deiner letzten Antwort nimmst du bereits einen weiteren Teil meines geplanten Konzepts vorweg: 🙂

    Ja, im Prinzip will ich daß der Datenbank-Server jeden "Furz" selbst erledigt, denn ich betrachte das RDBMS selbst als "Server-Applikation". Von einem erwachsenen RDBMS erwarte ich eigentlich, daß es die zahlreichen kleinen Anfragen von sich aus irgendwie chached.
    Microsoft hat einmal damit geworben, daß die Technologie-Börse NASDAQ das MS-SQL-Server System als Datenbank verwendet und es bis zu 5000 Transaktionen pro Sekunde (!) verarbeiten kann.

    Der Datenbank-Programmierer soll nur mit SQL, und den üblichen Erweiterungen dazu, zu tun haben. Er soll nicht viel neues lernen müssen. Die Synthax, die die Eingabemasken für die Client-Anwendung beschreibt, sollte dann so gestaltet werden, daß sie gut zur restlichen SQL-Sprache paßt.
    An SAP wird sowas vermutlich nicht heranreichen - soll es aber auch gar nicht, denn ich will dessen Aufgeblasenheit vermeiden.

    Witz: Weißt du was SAP bedeutet?
    - Sanduhr-Anzeige-Programm
    - Software-Aus-Pakistan
    - Schock-Angst-Panik 😉

    0

  • MS-SQL Server schafft sicher 5000 Transactions pro Sekunde, wenn das Storage-Backend passt (=schnelle Plattenstapel/SSDs), das Datenmodell vernünftig gewählt wurde und die Transaktionen alle ausreichend einfach/klein sind.

    Es gibt aber bestimmte Dinge die mit SQL Skripts einfach nicht gut funktionieren. z.B. das Arbeiten mit Baumartigen Strukturen. Seit SQL Server Common Table Expressions kann geht es viel besser, aber so wirklich toll ist es immer noch nicht.
    Ein einfaches SELECT mit WHERE root_node_id = xyz um den ganzen Baum aus der DB zu holen + weitere Verarbeitung in einem C++/C#/... Programm ist da oft um einiges schneller.

    Und ganz schlimm wird es mit reinen SQL-Skripts wenn man etwas nicht mehr mit Bulk-Statements erschlagen kann, und daher gezwungen ist Cursor' einzusetzen. Geh mal mit einem SQL Skript mit nem Cursor eine Tabelle mit 100K Zeilen durch, und dann mach das selbe mit einem Firehose-Cursor aus einer C#/C++/... Anwendung heraus. Der Unterschied ist dramatisch (zu Gunsten der C#/C++/... Anwendung). Ich weiss nicht genau wieso, aber es ist so. Leider.

    WENN die benötigten Abfragen/Transaktionen halbwegs einfach bleiben, das Datenmodell und die Umsetzung (Indexe, ...) passend gewählt sind, der DB-Entwickler wirklich weiss was er tut (was die meisten Leute die SQL so nebenbei gelernt haben leider nicht tun!) und man ein bisschen Glück hat, dann kann die Sache so halbwegs gut funktionieren.

    Wobei ich trotzdem nicht empfehlen würde den Client direkt mit der DB plaudern zu lassen. Speziell wenn du sowieso schon auf ein System abzielst wo die ganze Applikation rein Serverseitig programmiert und geändert werden kann ist der (dann geringe) Zusatzaufwand für eine "echte" Serverapplikation mMn. vertretbar.
    Im einfachsten Fall kann die Serverapplikation genau das machen was der Client sonst selbst machen würde. Also pro Client eine neue SQL Connection aufmachen und irgendwelche Stored-Procedures rausstarten.

    Was dann natürlich nicht mehr ganz so einfach geht ist fertige Controls zu verwenden und diese per Data-Binding an die DB dranzustoppeln. Wobei es auch da vermutlich irgendwelche brauchbaren Libs gibt, mittels derer man z.B. ein SQL-Server Recordset zum Client "durchreichen" kann, so dass dieser es mit Data-Binding an ein Control dranhängen kann.

    Fletcher schrieb:

    Witz: Weißt du was SAP bedeutet?
    - Sanduhr-Anzeige-Programm
    - Software-Aus-Pakistan
    - Schock-Angst-Panik 😉

    Stellenausschreibung für Arbeitssuchende Physiker?
    Schrecklich Abartige Perversion?
    Sechsbeiniger hund von AgiP?
    Kann man viel draus machen. Was es wirklich heisst musste ich aber auch auf WP nachschlagen.

    0
  • F

    Das mit den 5000 Transactions/sec habe ich zu einer Zeit gelesen, als es noch keine SSD's gab. Ich meine daher, daß die Datenbank im RAM-Speicher des Servers geladen gewesen sein muß, wobei der Server dann unbedingt USV-gepuffert sein muß - vor allem wenn Börsentransaktionen drüberlaufen.

    Wegen der "Cursor's": Mag sein daß C++ deutlich schneller ist, aber ist das auch noch so, wenn ich die Zeit dazurechne, die die 100k Datensätze brauchen um über ein verrauschtes WLAN zum Client zu gelangen? Da warte ich dann doch gerne ein paar Sekunden, bis sich der Server durchgekämpft hat und ich wieder nur wenige 100 Byte vom Server empfangen muß.

    WENN die benötigten Abfragen/Transaktionen halbwegs einfach bleiben, das Datenmodell und die Umsetzung (Indexe, ...) passend gewählt sind, der DB-Entwickler wirklich weiss was er tut (was die meisten Leute die SQL so nebenbei gelernt haben leider nicht tun!) und man ein bisschen Glück hat, dann kann die Sache so halbwegs gut funktionieren.

    Freut mich zu hören! 🙂
    Essenzielle Aussagen dieser Art, sind der Grund warum ich den Thread gestartet habe, um auszuloten, ob ich 1) nicht mit etwas beginne, das es ohnehin schon gibt und 2) das Projekt nicht zu einer Sackgasse wird bzw. unbrauchbar wegen schlechter Performance.
    Aber noch einmal, wenn ich mir anschaue was es im echten Leben für hatscherte Client-Server Anwendungen gibt, kann mein Vorhaben nicht so viel schlechter sein.

    Das mit den fertigen Controls und dem Data-Binding taugt mir nicht recht, weil mir da viele Möglichkeiten dieser Variante verborgen bleiben - das meine ich im negativen Sinn. Ich müßte jetzt wieder schauen, daß der User keine Möglichkeit hat das Control so zu verwenden, daß es zu unzulässigen Eingaben oder gar "Hacks" kommt.

    Danke hustbaer für alle deine bisherigen Antworten und Gedanken; ich möchte dir aber noch folgendes offenbaren - auf die Gefahr hin, daß du mich dann verbal erschlägst:
    Programmieren tue ich seit 1997 als VBA rauskam - und seither nur mit VBA, weil ich bis jetzt damit immer das Auslangen fand. Es gab damals in meiner alten Firma einen Fall der nach einer Excel-VBA Lösung rief. Da ich mit meiner regulären Arbeit in der Firma immer schnell fertig war, hatte ich viel Zeit mir VBA selbst beizubringen.
    Jetzt, 15 Jahre später, blicke ich doch schon auf einige Anwendungen zurück, die ich alle mit Excel-VBA Lösen konnte, darunter auch eine Dienstplanerstellung für bis zu 195 Mitarbeiter in einer Abteilung. Das Konzept davon ist seit über 10 Jahren in Verwendung, und ich habe es sogar geschafft Daten von Excel ins SAP zu übertragen (via Remote-GUI).

    Die nächsten Aufgaben die mir vorschweben, werde ich mit Excel-VBA nicht mehr lösen können - ich stehe jetzt an.
    Deshalb beginne ich erst jetzt mich in das WinAPI32 einzulesen, das Zusammenspiel mit C++, und SQL muß ich mir auch noch anschauen. Jetzt wirst dir denken "der Narr weiß nicht was er vor sich hat". Oh ja, wird sicher einige Zeit dauern, ich mache es nur als Hobby wenn ich Zeit und Lust habe. Auf der Basis werden wieder 10 Jahre vergehen, bis ich wirklich gut bin.
    Ich wollte nur, daß du diesen Background von mir weißt.

    0

  • Fletcher schrieb:

    Das mit den 5000 Transactions/sec habe ich zu einer Zeit gelesen, als es noch keine SSD's gab. Ich meine daher, daß die Datenbank im RAM-Speicher des Servers geladen gewesen sein muß, wobei der Server dann unbedingt USV-gepuffert sein muß - vor allem wenn Börsentransaktionen drüberlaufen.

    Das wird einfach ein ausreichend dickes RAID Array gewesen sein.
    Je nach Anwendung braucht man für die 5000 Transaktionen auch keinen super dicken Plattenstapel - wenn da sehr oft die selben Pages überschrieben werden dann kommt man mit einigen wenigen 15K Platten in einem RAID 5 aus.

    Und natürlich gibt es schon recht lange Zeit batteriegepufferte Ram-Disks. Die benötigen für die Datensicherheit nichtmal eine USV, weil sie ja ihre eigene "Notstromversorgung" mitbringen. Wobei man natürlich trotzdem eine verwendet, weil bei solchen Systemen ein kurzfristiger Ausfall und die darauf folgende lange Bootzeit enorm viel Geld kostet.

    0

  • Fletcher schrieb:

    Wegen der "Cursor's": Mag sein daß C++ deutlich schneller ist, aber ist das auch noch so, wenn ich die Zeit dazurechne, die die 100k Datensätze brauchen um über ein verrauschtes WLAN zum Client zu gelangen? Da warte ich dann doch gerne ein paar Sekunden, bis sich der Server durchgekämpft hat und ich wieder nur wenige 100 Byte vom Server empfangen muß.

    Wenn du ne echte Serverapplikation machst dann schickst du die Daten ja nicht über ein verrauschtes WLAN, sondern stöpselst den SQL-Server an den gleichen Switch an wo auch der Application-Server dranhängt.
    Bzw. oft lässt man die auch gleich auf dem selben Server laufen (entweder in zwei VMs am gleichen Host, oder wirklich in der gleichen OS Installation).

    WENN die benötigten Abfragen/Transaktionen halbwegs einfach bleiben, das Datenmodell und die Umsetzung (Indexe, ...) passend gewählt sind, der DB-Entwickler wirklich weiss was er tut (was die meisten Leute die SQL so nebenbei gelernt haben leider nicht tun!) und man ein bisschen Glück hat, dann kann die Sache so halbwegs gut funktionieren.

    Freut mich zu hören! 🙂
    Essenzielle Aussagen dieser Art, sind der Grund warum ich den Thread gestartet habe, um auszuloten, ob ich 1) nicht mit etwas beginne, das es ohnehin schon gibt und 2) das Projekt nicht zu einer Sackgasse wird bzw. unbrauchbar wegen schlechter Performance.

    Was es da schon gibt weiss ich wie gesagt nicht wirklich, also solltest du noch auf andere Antworten warten und/oder selbst ein wenig recherchieren.
    Was es auf jeden Fall gibt sind diverse RAD Umgebungen die speziell auf DB-Zeugs ausgelegt sind. PowerBuilder und so Zeugs.
    Und vonwegen schlechte Performance, davor versuche ich dich ja die ganze Zeit zu warnen, nur du willst es nicht wahrhaben 😉

    BTW: so lange der SQL Server die "heissen" Tabelle noch alle vollständig ins RAM bringt, kann man VIEL Unfug anstellen ohne dass man viel davon merkt. Wird die Datenbank dann aber irgendwann zu gross, fangen die Probleme an. Und dann ist es oft schon zu spät noch irgendwas zu ändern, hihi.

    Die nächsten Aufgaben die mir vorschweben, werde ich mit Excel-VBA nicht mehr lösen können - ich stehe jetzt an.
    Deshalb beginne ich erst jetzt mich in das WinAPI32 einzulesen, das Zusammenspiel mit C++, und SQL muß ich mir auch noch anschauen. Jetzt wirst dir denken "der Narr weiß nicht was er vor sich hat". Oh ja, wird sicher einige Zeit dauern, ich mache es nur als Hobby wenn ich Zeit und Lust habe. Auf der Basis werden wieder 10 Jahre vergehen, bis ich wirklich gut bin.
    Ich wollte nur, daß du diesen Background von mir weißt.

    Ich würde dir zu C# raten.
    C# zu lernen sollte wenn man von VBA kommt viel viel schmerzfreier und vor allem schneller gehen als C++ zu lernen.
    Und auch die üblichen Datenbank-Interfaces in C# sind viel angenehmer zu verwenden als in C++.
    Und falls du doch meinen Rat beherzigen solltest, und eine echte Serverapplikation baust, dann geht das mit C# auch ungefähr 10x einfacher als mit C++.
    Vor allem wieder unter der Voraussetzung dass man beide Sprachen neu lernen muss, und davor nur mit VBA gearbeitet hat.

    0
  • F

    Da mein Vorhaben nur ein 1 Mann-Projekt ist, dieses nur in der Freizeit zum Üben betrieben wird, und das auch nur dann wenn ich Lust dazu habe, werde ich die Zwischenebene mit dem Application-Server zu Beginn einfach mal weglassen, sonst komme ich vom hundertsten ins tausendste.

    Wie die Performance dann wirklich ist, werde ich schon sehen.
    Unter schnell verstehe ich, daß wenn Client-Anwendung und die DB am gleichen PC installiert ist, das Ergebnis am Bildschirm steht, noch bevor die Fingerkuppe von der Enter-Taste abhebt.

    Daß C# 10x einfacher ist als C++ wird schon stimmen, aber es ist eine Sprache die das .NET-Framework braucht - will ich nicht! Und wenn ich schon eine neue Sprache lerne, dann kann es ruhig gleich C++ sein; ich habe nämlich schon einmal irgendwo in einer vereinfachten C-Synthax programmiert (es war nicht C#), war nicht so schwer.
    Am Ende soll eine saubere native x86-Anwendung rauskommen - im Idealfall gibt es nur eine EXE-Datei die nicht einmal installiert werden muß.

    Ich habe auch schon überlegt, ob ich nicht PureBasic dafür verwende; nur ist mir das zu unsicher im Hinblick auf Support in ferner Zukunft. (Hinter PureBasic stehen angeblich nur 2 Leute).
    Was mit PureBasic auf jeden Fall geht ist native x86-Anwendungen zu erstellen, und sogar die gesamte PureBasic-Entwicklungsumgebung kann ohne Installation direkt vom USB-Stick aus gestartet werden. Ideal um auf eingeschränkten Firmen-PCs das eine oder andere kleine EXE-Tool zu programmieren um dort lästige Systemeigenschaften zu auszutricksen. 🙂

    0
  • N

    Ok, nochmal zum mitschreiben: Den App-Server lässt du aus Zeitgründen weg, aber du lernst schnell mal eben C++ um deine Anwendung zu schreiben? 😮

    Wenn du ohnehin überlegst, einen MSSQL-Server zu verwenden, schreib dein GUI einfach in C# und fertig. Wenn du ohnehin bei Microsoft-Zeugs bleibst, nutze auch deren Toolchain, das macht alles viel bequemer und einfacher und für Windows-GUI-Zeugs ist C# einfach unheimlich praktisch.

    Alternativ kannst du auch eine Sprache verwenden, die du schon kennst. Überleg dir einfach, ob du primär eine neue Sprache lernen möchtest oder das Projekt fertigbekommen möchtest.

    0
  • F

    Zum Glück ist es so, daß ich hier nicht unter Zeitdruck stehe und gar nichts fertigbekommen muß.
    Vielleicht ergeben sich bei mir auch neue Lebensumstände, die helfen dieses Projekt zu beschleunigen, oder aber auch Umstände die mich dazu zwingen das ganze komplett zu vergessen......
    Es wäre nur ein mögliches Endprodukt das mir vorschwebt. Auf dem Entwicklungsweg dorthin, liegen noch viele andere Steine im Weg, wie z.B. wie erstelle ich einen Button dynamisch zur Laufzeit? Wie lasse ich ihn auf Mausereignisse reagieren? usw. (Das will ich selbst herausfinden, und wenn ich nicht schaffe lasse ich es ohnehin bleiben)

    Um native Windows-Anwendungen zu schreiben, habe ich mir einmal den Windows-SDK runtergeladen. Dort ist C++ enthalten (und nur C++); es wird schon einen Grund haben warum das so ist. Wenn Microsoft es mir wirklich einfach machen möchte, müßten sie Visual Basic so gestalten, daß man auch nur damit native x86-Anwendungen erstellen kann. Mit VB 6.0 im Jahr 2000(?) ging das noch!

    Das nächste ist das WinAPI: Wenn es auf Windows laufen soll, wäre es nicht schlecht zu wissen, wie es "bedient" werden muß. Auch bei PureBasic hätte ich mich mit der WinAPI vertraut machen müssen, weil ohne dem offenbar nichts geht.

    Erst wenn ich soweit bin, daß ich Fenster und Steuerelemente nach belieben gestalten und manipulieren kann, kommt SQL - "zum Darüberstreuen".

    Es ist alles im Moment rein persönliches Interesse "zum Privatvergnügen", da werde ich mich selbst nicht unter Druck setzen. Wäre ich arbeitslos und würde einen IT-Job suchen, sähe die Sache schon anders aus.

    0
  • N

    Ehrlich gesagt klingt das stark so, als hättest du dir ein bisschen zu viel vorgenommen.

    WinAPI und C++ gleichzeitig zu lernen ist keine gute Idee. Das 2012 noch für ein komplett neues Projekt einzusetzen auch nicht; niemand schreibt mehr Anwendungen in WinAPI. Aber frag wegen deiner GUI- und sonstigen Fragen bitte lieber in einem anderen Subforum hier nach. Hier gibt's weniger Windows-GUI-Spezialisten.

    Deine DB-Fragen hat hustbaer dir schon kompetent beantwortet, seinen Ausführungen ist nicht mehr viel hinzuzufügen: Du kannst dich entweder auf die Empfehlungen von Leuten mit viel Erfahrungen verlassen oder sie ignorieren. Für letzteren Fall brauchst du aber eigentlich keine Forenposts. 🙂

    0

  • Fletcher schrieb:

    Daß C# 10x einfacher ist als C++ wird schon stimmen, aber es ist eine Sprache die das .NET-Framework braucht - will ich nicht!

    Grund?

    Und wenn ich schon eine neue Sprache lerne, dann kann es ruhig gleich C++ sein; ich habe nämlich schon einmal irgendwo in einer vereinfachten C-Synthax programmiert (es war nicht C#), war nicht so schwer.

    Das kann jetzt nicht dein Ernst sein?
    *Hab schon mit was mit geschwungenen Klammern gemacht und das war OK, also kann C++ nicht so schwer sein.
    *Wo ist der Smiley der sich mitm Hammer aufn Kopp haut, ich brauch den grad dringend!

    Du unterschätzt MASSIV die komplexität von C++.

    Am Ende soll eine saubere native x86-Anwendung rauskommen - im Idealfall gibt es nur eine EXE-Datei die nicht einmal installiert werden muß.

    Dann such dir irgend ein RAD Toolkit das eigenständige .exen ausspucken kann.
    Wobei ...

    Ich habe auch schon überlegt, ob ich nicht PureBasic dafür verwende; nur ist mir das zu unsicher im Hinblick auf Support in ferner Zukunft. (Hinter PureBasic stehen angeblich nur 2 Leute).

    ...DAS Problem hast du bei den meisten RAD Tookits auch. Wobei hinter den meisten mehr als 2 Leute stehen. Trotzdem kann es schnell passieren dass ein solches Produkt eingestellt wird. Und da die oft ne eigene Programmiersprache haben, bzw. ein eigenes Framework mitbringen von dem alles abhängt, steht man dann auch ziemlich blöd da.

    Was mit PureBasic auf jeden Fall geht ist native x86-Anwendungen zu erstellen, und sogar die gesamte PureBasic-Entwicklungsumgebung kann ohne Installation direkt vom USB-Stick aus gestartet werden. Ideal um auf eingeschränkten Firmen-PCs das eine oder andere kleine EXE-Tool zu programmieren um dort lästige Systemeigenschaften zu auszutricksen. 🙂

    Ist jetzt die Frage anhand von was du entscheiden willst in welche Technologie du die nächsten 2-5 Jahre deiner Freizeit investieren willst.
    In eine Technologie die Zukunft hat und für sich genommen Sinn macht, oder in etwas mit dem man die beknackte Anforderung "ich darf nix installieren" erfüllen kann.

    0
  • F

    Im Vergleich PC zu Commodore C64, entspricht .NET dem C64-BASIC und C++ der Maschinensprache des C64. Spiele für den C64 konnten nur direkt mit der Maschinensprache geschrieben werden, da der ganze BASIC-Overhead so viel Rechenleistung und Speicherplatz beanspruchte, daß eben keine "komplexen" Spiele mit BASIC möglich waren.

    Auf meinem PC ist eine .NET-Anwendung installiert - es ist die "aquasuite" von Aqua-Computer - mein PC ist nämlich wassergekühlt. Beim Umschalten der verschiedenen "Masken" am Bildschirm hat man das Gefühl man blättert ein Buch um, weil es genau einen so kurzen Moment dauert bis der Bilschirmbereich neu gezeichnet worden ist. Sie verhält sich generell etwas träge.

    Wenn ich .NET verwende kann ich gleich bei Excel-VBA bleiben, denn .NET ist nur der Mittler zum eigentlichen System. Jeder in C# oder VB geschriebene Code wird in .NET nocheinmal umgewandelt. Damit ja alle Möglichkeiten abgedeckt werden, ist der weitergereichte Maschinen-Code immer recht generisch gehalten - Overhead!
    Man kann in Excel-VBA auch WinAPI-Funktionen aufrufen, wenn man weis wie's geht. "GetTickCount" habe ich mir schon öfters geholt - zur Performance-Messung meiner Programm-Algorithmen. SQL-Strings senden und empfangen geht auch.
    Ich habe sogar schon Audio-Files offline bearbeitet; das hat mit einer Tabellenkalkulation nichts mehr zu tun, geht aber trotzdem.

    Ob ich C++ MASSIV unterschätze, werde ich selbst sehen; aber ich sage jetzt ganz keck: Vielleicht unterschätzt du ja nur mich 😉

    Auf welche Technologie ich setzen soll? Das x86-Konzept wird uns noch länger erhalten bleiben - genau so wie in den Autos nach über 100 Jahren noch immer Kolbenmaschinen laufen, und noch immer neue Audio-CDs nach dem technischen Stand von 1983 produziert werden.
    Ob aber die Metro-Overfläche von Windows 8 in Windows 9 oder 10 noch enthalten ist wage ich zu bezweifeln. Zum Glück gibt's "Classic-Shell" 🙂

    0
  • M

    Fletcher schrieb:

    Auf meinem PC ist eine .NET-Anwendung installiert - es ist die "aquasuite" von Aqua-Computer - mein PC ist nämlich wassergekühlt. Beim Umschalten der verschiedenen "Masken" am Bildschirm hat man das Gefühl man blättert ein Buch um, weil es genau einen so kurzen Moment dauert bis der Bilschirmbereich neu gezeichnet worden ist. Sie verhält sich generell etwas träge.

    Das sind Vorurteile, die durch paar schlechte Anwendungen bekräftigt werden. Ich habe jahre lang als C# Entwickler gearbeitet. Der Performanceunterschied ist meist kaum messbar und so gut wie nie spürbar, erst recht nicht bei so trivialen Sachen wie GUI. Und dir gehts ja nicht grad um HPC Computing. Vor allem bei verteilten Anwendungen würd ich eher .NET bevorzugen.

    Ich würd einfach mal keck behaupten, du überschätzt dich selber 😉 Aus dem was ich so rausgelesen habe, würd ich sagen, du kennst dich generell "recht gut aus", aber dir fehlt das Wissen und die Erfahrung, was Softwarearchitekturen angeht. SAP ist kein "einfaches Client/Server System" 😉 Man sollte schon deutlich mehr Ahnung von sowas haben, bevor man sowas angeht. Es kann schon gut sein, dass du irgendwann ein funktionierendes, vielleicht gut funktionierendes System auf die Beine bekommst, mit dem man auch eine Weile arbeiten kann. Aber aus der Sicht eines Softwareentwicklers wird es sehr wahrscheinlich keine wartbare/erweiterbare Basis haben. Irgendwann kommen immer neue Anforderungen, oder du bist irgendwann weg, und die Firma entschließt sich, das Projekt an extrene Softwareentwickler zu geben und die werden sich nur denken "WTF???".
    Ich sage das nicht, um dich zu beleidigen oder zu entmutigen. Ich habe das einfach schon zu oft erlebt. Ohne die entsprechenden Kenntnisse und Erfahrung (und die hast du nicht, sonst würdest du so eine Frage nicht stellen, oder nicht in der Form stellen) lassen sich solche Anwendungen einfach nicht aus dem Boden stampfen. Alles was man sich selber irgendwie überlegt, funktioniert nur bis zu einem gewissen Grad. Danach führt es nur zu einer weiteren unwartbaren Lösung, die irgendwann teuer abgelöst werden muss. Ich musste schon in mehreren Firmen solche Projekte ablösen. Das mag sogar nach außen gut funktionieren, schließlich haben die Firmen damit jahrelang gearbeitet, aber intern ist es meist zum Haare raufen. Bevor du ein weiteres solches System anfängst, überleg dir lieber gut, ob du dich wirklich gut genug auskennst (und ich meine nicht "programmieren"), und ob dir eine Antwort in so einem Forum reicht.

    0
  • F

    Daß du meinst, ich kenne mich "recht gut aus", ist mir schon Lob genug 🕶

    Das Wissen und die Erfahrung über Software-Architekturen fehlt mir sicher, denn ein Projekt in der Größe habe ich noch nie gemacht. Es sei bitte gesagt, daß ich alles was ich bisher gemacht habe, neben meiner eigentlichen Arbeit getan habe (schon während der Arbeitszeit aber eben neben der Hauptaufgabe, weil IT-Tätigkeiten in meinem Bereich gar nicht vorgesehen sind.)

    Ich will mein "Projekt" ja gar nicht auf SAP-Level bringen, denn dazu würde ich gar nicht lang genug leben.
    Sind die Möglichkeiten des Frontends aber zu stark eingeschränkt, entsteht der Wunsch der User nach mehr; Und wenn man nicht aufpasst ist die Synthax bald so komplex, daß man gleich ABAP von SAP nehmen hätte können.

    Allgemein: Wenn Programmänderungen so kompliziert werden, daß sie nicht mehr mit der Geschwindigkeit, der von außen erzwungenen Prozeßänderungen, mithalten können, muß man das bestehende System hinterfragen ob es so noch Sinn macht. Es besteht dann die Gefahr, daß der Mensch der Maschine dient und nicht umgekehrt. Heutzutage ist diese "Diener"-Umkehr recht oft anzutreffen; sie wird akzeptiert, weil eine Ersatzlösung zu teuer ist, nicht schnell genug verfügbar und auch sonst alles zusammenbrechen würde.

    Betreffed der "unwartbaren Lösungen": Die werden immer entstehen. Glaubst Du das weder Deine, noch meine Lösungen im Jahr 2032 noch irgendwie zum Rest passen?

    0
  • F

    Zufällig sehe ich einen ganz anderen Thread hier im C++/MFC-Forum "VS2010, MFC Programme werden größer?"

    Das ist genau das weshalb ich vorerst versuche ohne .NET, ATL und MFC auszukommen - weil hier immer "fremde" Komponenten zwischengeschaltet sind, über die ich keine Kontrolle habe!
    Komponenten die bei einem Versionsupdate mein eigentliches Programm beeinträchtigen könnten, weil es jetzt Features gibt, die mit dem Rest des Programms nicht harmonieren.

    .NET oder MFC würden mir viel Programmierarbeit abnehmen - weiß ich - aber vorerst strebe ich einmal nach Unabhängigkeit.

    0
  • S

    Fletcher schrieb:

    Zufällig sehe ich einen ganz anderen Thread hier im C++/MFC-Forum "VS2010, MFC Programme werden größer?"

    Das ist genau das weshalb ich vorerst versuche ohne .NET, ATL und MFC auszukommen - weil hier immer "fremde" Komponenten zwischengeschaltet sind, über die ich keine Kontrolle habe!

    Dann wuerde ich aber auch keine C++ Library Sachen wie std::string oder std::cout verwenden. Und lieber garnicht erst die API deines Betriebssystems benutzen sondern besser ein eigenes Schreiben. Aber lieber nicht auf herkoemmlicher Hardware - besser du designest deine Hardware selbst. Ich wuerde mich dabei aber nicht auf die herkoemmliche Forschung verlassen sondern lieber das mit den Transistoren nochmal ueberdenken ob da nicht was besseres geht.

    Dann kannst du in dem Zug auch gleich eigenen Storm produzieren damit die Spannung perfekt zu deiner neuen Hardware passt und du nicht umwandeln musst und wer weiss schon was da fuer Schrott im Stromnetzwerk drinnen ist - lieber unabhaengig sein.

    0
  • F

    Du mußt meine Haltung natürlich gleich übertreiben 🙄
    C/C++, gerne mit Standardlibrary 😉 , und WinAPI sind schon die Grundbausteine.

    Ich wuerde mich dabei aber nicht auf die herkoemmliche Forschung verlassen sondern lieber das mit den Transistoren nochmal ueberdenken ob da nicht was besseres geht.

    Du wirst lachen, das tun andere bereits: Schau einmal bei Wikipedia unter "Graphen". Bei Silizium ist praktisch bei 5 GHz Taktfrequenz schluß, mit den Graphen werden 500 GHz und mehr möglich sein.....

    Evolution der Schaltelemente: Relais, Röhre, Transistor, Graphen.

    Apropos Relais: Der (Konrad) Zuse Z3 Relaisrechner wurde vom Sohn des Erbauers mit modernen Relais nachgebaut - schau auf Youtube. Ich finde dieses Projekt insofern interessant und sinnvoll, daß man sich einmal wieder darauf besinnen sollte, wofür jeder einzelne Schalter im Prozessor gut ist - Stichwort: "Rechenwerke". Es wird ja hoffentlich keiner behaupten, daß ein Programmierer 1,4 Milliarden Transistoren in einem Core-i5 voll unter Kontrolle hat.

    Bei .NET und Java wird ganz offen gesagt, daß der interne Programmoverhead durch die Rechenleistung heutiger Prozessoren kompensiert wird. Dafür bekommt man recht schnell eine Anwendung fertig.

    0
  • S

    Fletcher schrieb:

    Bei .NET und Java wird ganz offen gesagt, daß der interne Programmoverhead durch die Rechenleistung heutiger Prozessoren kompensiert wird. Dafür bekommt man recht schnell eine Anwendung fertig.

    Du hast einfach eine falsche Vorstellung von Softwarearchitektur 😕

    0

  • @Fletcher
    Du hast eine vollkommen falsche Vorstellung von .NET. Was du schreibst ist völliger Quatsch. Der Schluss von einem .NET Programm auf .NET im Allgemeinen entbehrt jeglicher Logik. Der Vergleich VBA <-> C# ist auch reichlich lächerlich. Und ich garantiere dir dass du die Komplexität der Sache unterschätzt.

    Was Softwarearchitektur angeht: wenn man das kann, dann kann man durchaus auch recht komplexe Software so bauen dass Änderungen leicht möglich sind. Und wenn man es nicht kann, dann braucht es keine 30 oder 100 Jahre bis man vor einem völlig unwartbaren Haufen steht. Je nachdem wie schlecht man wirklich ist, und wie oft man Änderungen vornimmt kann man das in ein paar Wochen hinbekommen.

    Aber OK, nachdem du vollkommen beratungsresistent bist und nur das bestätigt bekommen wolltest was du sowieso schon vor hattest: ja, lern C++ und schreib ne Anwendung die direkt auf den SQL-Server hingreift. Ist ne richtig gute Idee 👍

    0
  • F

    OK Leute, mag sein daß ich von Softwarearchitektur nicht viel verstehe; ich weiß aber ganz genau wie das Endprodukt aussehen soll und wie es performen soll. Schaffe ich es nicht die Anwendung so zu erstellen, daß sie nach meinem Begriff gut performed, muß ich das ohnehin mit mir selbst ausmachen.

    Ich habe nie behauptet daß mein Vorhaben zwischen 2 Tassen Kaffee erledigt werden kann. Ich habe auch nie gesagt, daß die Combo C++ und SQL-Server das gelbe vom Ei ist. Ich wollte einfach Meinungen dazu hören, und ich habe sie gehört. Die Bringschuld liegt jetzt bei mir, damit zu Beginnen und eventuell an dieser Stelle über erste Ergebnisse zu berichten - was aber viele Wochen dauern kann, weil --> Freizeitprojekt neben einem Nicht-IT-Fulltimejob.

    Das schöne an der IT ist, daß von Anfang an absolute Gleichberechtigung herrscht: Während man bei vielen Berufen eine höhere Ausbildung oder gar ein Studium vorweisen muß, spricht es für sich wenn es 14-Jährige gibt die in den Pentagon-Computer eindringen können (nur ein symbolisches Beispiel). Der 14-Jährige hat per sofort bewiesen, daß er über stark überdurchschnittliche Computerkenntnisse verfügen muß.

    Ich erinnere nocheinmal an mein 1.Posting in diesem Thread: Eine 70er-Jahre Kiste mit Terminal-Emulatoren bringt angeforderte Daten in weniger als 0,3s auf den Bildschirm, während heutige Plattformen schon 0,3s brauchen damit sie das "Loading"-PopUp mit dem drehenden Kreis anzeigen?!?! Hier stimmt doch etwas nicht!

    0
  • S

    Fletcher schrieb:

    OK Leute, mag sein daß ich von Softwarearchitektur nicht viel verstehe; ich weiß aber ganz genau wie das Endprodukt aussehen soll und wie es performen soll. Schaffe ich es nicht die Anwendung so zu erstellen, daß sie nach meinem Begriff gut performed, muß ich das ohnehin mit mir selbst ausmachen.

    Nur weil ich weiss wie eine Rakete aussieht, bin ich noch lange kein Raktentechniker.

    Ich erinnere nocheinmal an mein 1.Posting in diesem Thread: Eine 70er-Jahre Kiste mit Terminal-Emulatoren bringt angeforderte Daten in weniger als 0,3s auf den Bildschirm, während heutige Plattformen schon 0,3s brauchen damit sie das "Loading"-PopUp mit dem drehenden Kreis anzeigen?!?! Hier stimmt doch etwas nicht!

    Solche Aussagen machen mich sprachlos und lassen mich an der Menschheit zweifeln.

    0
Anmelden zum Antworten