spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

Wie bereits gesagt ist es mir nicht wichtig ob ich jetzt 5-15Euro für einen VServer ausgeben kann, sondern ich möchte den Aufwand und die Kosten für den eventuellen Drittnutzer (aka Administrator) so gering wie möglich halten.

Ach jau, na dann aber doch vielleicht PHP? Würde ich noch eher als de facto Standard betrachten als Python oder Ruby.
Wobei das auch gut geht, lass dich nicht aufhalten

Zitat

Warum ist eine NoSQL-DB fürs Web besser geeignet?
Ich meine die Frage ernst, denn mir scheint es so, als ob NoSQL nur für einige Anwendungsgebiete tatsächliche Vorteile bringt.

Das hängt auch stark von der Anwendung ab. Im Web Bereich möchte man normalerweise schnelle Zugriffszeiten, im Vergleich zu z.B. einer Batch Verarbeitung. Und da sind relationen evt. langsamer.
Ein Beispiel das häufig genannt wird sind Blogposts: anstatt eine Tabelle für Blogposts und eine für Kommentare zu haben, werden die Kommentare am Blogpost Dokument mit gespeichert. Ließt man jetzt (möglichst effizent über die ID z.B.) den Blogpost aus, bekommt man direkt alle Kommentare mit geliefert.
Es gibt noch andere Vorteile, z.B. bilden Dokumente Entitäten im Programm besser ab als relationale Datenbanken (man braucht keinen Mapper um zu zerlegen/zusammen zu bauen).
Und viele mehr. Das wäre vielleicht mal ein eigenes Thema wert.

Zitat von »DeKugelschieber«

Das hängt auch stark von der Anwendung ab. Im Web Bereich möchte man normalerweise schnelle Zugriffszeiten, im Vergleich zu z.B. einer Batch Verarbeitung. Und da sind relationen evt. langsamer.
Ein Beispiel das häufig genannt wird sind Blogposts: anstatt eine Tabelle für Blogposts und eine für Kommentare zu haben, werden die Kommentare am Blogpost Dokument mit gespeichert. Ließt man jetzt (möglichst effizent über die ID z.B.) den Blogpost aus, bekommt man direkt alle Kommentare mit geliefert.
Es gibt noch andere Vorteile, z.B. bilden Dokumente Entitäten im Programm besser ab als relationale Datenbanken (man braucht keinen Mapper um zu zerlegen/zusammen zu bauen).
Und viele mehr. Das wäre vielleicht mal ein eigenes Thema wert.

Naja, gerade dieses Beispiel ist nicht so günstig, da einerseits das Datenmodell hier nicht flexibel sein muss (Blogpost und Kommentare lassen sich hier recht einfach als Tabellen abbilden) und ich hier zu behaupten wage, dass es keine Performanzeinbußen gegenüber einer relationalen Datenbank gibt.

Müsste man jetzt Daten über mehrere Relationen zusammensuchen, dann könnte NoSQL evtl. von Vorteil sein. Könnte, muss aber nicht. Kommt auch ein bisschen auf das Datenmodell selbst an.
Ich denke eher, dass NoSQL bei flexiblen Datenmodellen Sinn macht, also bei Datenmodellen, wo man das Modell sozusagen zur Laufzeit noch erweitern können muss. Und selbst bei diesem Anwendungsfall habe ich Lösungen gesehen, welche auf RDBMS basieren und trotzdem hochperformant waren.

Wobei ich nicht gegen NoSQL bin, versteh mich bitte nicht falsch, aber ich denke, dass man gerade bei solch trivialen Anwendungsfällen nicht unbedingt zu NoSQL greifen muss.

Zitat von »TrommlBomml«

Allerdings ist man auch von den gefühlt eine Millionen Javascript Frameworks mehr als überfordert. Eh man da was gefunden hat, was man WIRKLICH braucht, muss man meiner Meinung nach erstmal eine komplette Webanwendung bauen.

Dass Startups die ganzen "alternativen" Benutzen macht ziemlich sinn, weil das alles OpenSource und kostenlos ist. Wenn du aber Richtung Sharepoint/ Windows Server gehst, was bei durchaus vielen Firmen, die sowieso auf Microsoft setzen, sehr üblich ist, wird da auch nach ASP.NET geschriehen. Ganz abgsehen jetzt mal von der ganzen, mächtigen Java Application Server sparte...

Ich denke der Grund liegt weniger in den Kosten, Startups haben teilweise verdammt viel Geld und kosten fuer Sharepoint/etc sind vernachlaessigbar im vergleich zu Gehaeltern, etc. Der Grund liegt denke ich eher darin, dass die Technologien recht neu sind. Ne grosse Firma mit hunderten Microsoft-zertifizierten Entwicklern, Millionen Codezeilen in ASP, etc kann nicht mal eben sagen "Jo lass mal NodeJS und MongoDB machen"!
Startups versuchen oft mit dem geringsten Entwickler und Zeitaufwand das Ziel zu erreichen und sind frei Technologien zu waehlen wie sie wuenschen. Die Anforderungen sind idR auch anders, ne stabile Firma moechte eher ein starres, aber verlaessliches system. Nen Startup moechte flexibel bleiben.

Wobei es mir auch scheint, dass vieles davon einfach Modeerscheinungen sind. NodeJS, Scala, MongoDB sind gerade hip.. PHP und MySQL ist der langweilige altmodische Kram.

Wenn dein primaeres Ziel ist, dass deine Nutzer es moeglich einfach und guenstig haben dein Produkt zu nutzen, dann wuerde ich entweder:
a) Hosting selbst anbieten. Viele CMS heutzutage werden nicht mehr auf dem eigenen Webspace installiert, sondern als Dienst angeboten.
b) PHP und MySQL benutzen. Es ist das einzige was wirklich weit verbreitet ist und auf so gut wie jedem noch so guenstigen webspace laeuft.

Mit Python muesstest du im schlimmsten Fall ueber CGI gehen was recht schwierig im Setup wird und auch nicht sonderlich flott ist. So gerne ich Python auch benutze, ich glaube fuer das Ziel ist es nicht so gut geeignet. Selbes gilt fuer so ziemlich jede andere Sprache.

Solltest du bei Python bleiben kann ich generell empfehlen:
- Flask sehr schlankes framework fuer Webanwendungen
- Schreib fuer alles unittests. Da du quasi keine Compiler Error in Python bekommst ist es unheimlich wichtig, dass in den Tests der Code wenigstens einmal ausgefuehrt wird um Fehler zu finden.

Zitat von »h_dev«

Zitat von »DeKugelschieber«

Das hängt auch stark von der Anwendung ab. Im Web Bereich möchte man normalerweise schnelle Zugriffszeiten, im Vergleich zu z.B. einer Batch Verarbeitung. Und da sind relationen evt. langsamer.
Ein Beispiel das häufig genannt wird sind Blogposts: anstatt eine Tabelle für Blogposts und eine für Kommentare zu haben, werden die Kommentare am Blogpost Dokument mit gespeichert. Ließt man jetzt (möglichst effizent über die ID z.B.) den Blogpost aus, bekommt man direkt alle Kommentare mit geliefert.
Es gibt noch andere Vorteile, z.B. bilden Dokumente Entitäten im Programm besser ab als relationale Datenbanken (man braucht keinen Mapper um zu zerlegen/zusammen zu bauen).
Und viele mehr. Das wäre vielleicht mal ein eigenes Thema wert.

Naja, gerade dieses Beispiel ist nicht so günstig, da einerseits das Datenmodell hier nicht flexibel sein muss (Blogpost und Kommentare lassen sich hier recht einfach als Tabellen abbilden) und ich hier zu behaupten wage, dass es keine Performanzeinbußen gegenüber einer relationalen Datenbank gibt.

Müsste man jetzt Daten über mehrere Relationen zusammensuchen, dann könnte NoSQL evtl. von Vorteil sein. Könnte, muss aber nicht. Kommt auch ein bisschen auf das Datenmodell selbst an.
Ich denke eher, dass NoSQL bei flexiblen Datenmodellen Sinn macht, also bei Datenmodellen, wo man das Modell sozusagen zur Laufzeit noch erweitern können muss. Und selbst bei diesem Anwendungsfall habe ich Lösungen gesehen, welche auf RDBMS basieren und trotzdem hochperformant waren.

Wobei ich nicht gegen NoSQL bin, versteh mich bitte nicht falsch, aber ich denke, dass man gerade bei solch trivialen Anwendungsfällen nicht unbedingt zu NoSQL greifen muss.

Stimmt war ein zu simples Beispiel. Es hängt von der Anwendung, vom Datenmodell und von den persönlichen vorzügen ab.
Ich finde SQL z.B. einfach auch nicht besonders gut. Da hat man einen Bruch zwischen seiner Programmiersprache und der Datenbank. Dafür ließe sich eine RDB einfacher austauschen als mongodb.
Naja eigenes Thema.

Bitte nicht WebServer mit ApplicationServer verwechseln. ;-)

Also ich stelle mir immer die folgenden Fragen. Müssen meine Daten normalisiert sein oder müssen sie das nicht? Ist es mir egal in welcher Form meine Daten sind oder ist es das nicht? Lege ich Wert auf eine Normalisierung? Bei einem CMS würde ich die Fragen mit Ja beantworten und eine Relationale Datenbank verwenden.

Der Nachteil ist jedoch, dass wenn ich die Objekte ändere ich auch die Datenbank anpassen muss.

Schöne Grüße

fb

Der riesige Vorteil von NoSQL ist (horizontale) Skalierbarkeit. Joins über Daten, die auf verschiedenen Servern liegen, ist ein Performancetod. Letztendlich muss man also bei SQL die Daten zusammengehörend auf einzelne Server partitionieren. Das ist dann praktisch wie Dokumentenorientiert, nur unständlicher.

Man muss aber bei NoSQL immer bedenken das man für die Performance die man bekommt auch sehr schnell an Funktionalität verliert. Solange die Skalierbarkeit kein kritischer Faktor ist, würde ich nicht von SQL abraten. MongoDB z.B. hat zwar noch recht gute Query Möglichkeiten, ist aber bei Referenzen schon eingeschränkter und sowas wie "Gib mir die Augenfarben aller Freunde von Benutzer x" ist da schon deutlich unschöner als es in relationalen Datenbanken ist. Für gute Performance in solchen Komplexen fällen braucht man dann relativ viele Indizes, was wieder gegen das DB Konzept an sich geht.

Um mal deinen Titel auf zu greifen: "Moderne Web Entwicklung"

In dem Zusammenhang beißt sich etwas der spezifische Gedanke ob nun nodejs, go, php oder was auch immer als “Backend” zu benutzen.

Dein CMS sollte meine Meinung nach simpel von einem x beliebigen Server transportiert werden können. Sprich aus html/js/css bestehen.

Die Kommunikation findet dann per ReST/Websocket oder was auch immer, sehr definiert statt. Hier kannst du dann ja z.B eine Referenz-Implementation deines Application Servers anbieten (der teilweise heut zu Tage erschreckend einfach aufgebaut ist, da das Meiste in der Application im Browser abläuft).

So bleibst und bietest du viel mehr Flexibilität. Und kannst zwei getrennte Seiten anbieten, die jeder bei Bedarf leicht ersetzen kann.

Zumindest wäre dies in meinen Augen ein modernerer Ansatz. Sprich Web Application Entwicklung statt der Klassischen.

Falls du, anti-freak, dich doch noch für PHP entscheidest, kann ich dir diese Seite ans Herz legen: http://www.phptherightway.com/

Zitat von ebendieser Seite:

Zitat von »PHP: The Right Way«

There’s a lot of outdated information on the Web that leads new PHP users astray, propagating bad practices and insecure code. PHP: The Right Way is an easy-to-read, quick reference for PHP popular coding standards, links to authoritative tutorials around the Web and what the contributors consider to be best practices at the present time.

Clientseitig, und da du Visual Studio gerne benutzen möchtest, kann ich TypeScript empfehlen. Habe selber meine JS -Anwendung, als sie auf 5000 Zeilen gewachsen war in Typescript übersetzt. Neben einigen Fehlern die die Migration aufgezeigt hat ist das Arbeiten erheblich angenehmer mit Typescript.


Aus meiner Erfahrung haben Mittelständler oft MS im Einsatz - Serverseitig würde also eine IIS Anwendung (C#) möglich sein. Allerdings bin ich nun mal auch nur im MS Umfeld tätig...
Leute die Open Source Projekte umsetzen werden dir wahrscheinlich genau das Gegenteil erzählen

REST und andere API-designs solle man einsetzen, wenn sie auch Sinn machen.
Striktes REST für eine reine Webseite macht meiner Meinung nach nur bedingt Sinn, da sie hier und da dem desgin widersprechen würde (admin-system, user-system, session speichern, template-system..).

Datenbank-Normalisierung ist schön und gut .. in der Theorie.
In der Praxis kommt man immer an Tabellen, welche bei korrekter Normalisierung mehr Last verursachen als gewisse Daten einfach doppelt zu speichern. Usernamen in großen Ranglisten ists z.B. in unseren games. Es ist nicht praktikabel bei solchen queries auch noch die entsprechend große char-Tabellen abzufragen, nur um den Namen zu finden. Evtl. liegen die auch verteilt auf verschiedenen servern... viel Spaß mit Normalisierung.
Es ist vollkommen ok, dabei Vor- und Nachteile abzuwägen. Man sollte eben nur drauf achten, dass diese Werte konsistent bleiben oder beim nächsten update einfach fix geupdated werden (z.B. bei Punkteänderung in der Rangliste einfach den Namen mit ins query packen).

Zitat

Warum ist eine NoSQL-DB fürs Web besser geeignet?

Das kann man konkret nicht einfach so behaupten und ich behaupte auch eher das genaue Gegenteil.
Besonders wenn es leicht portabel bleiben soll, ist noSQL immernoch eher zweite Wahl.
Nutz lieber normales sql mit php's PDO-Implementierung. Kleine Datenbankklasse geschrieben und fertig.

Du kannst dir ja auch noch Dinge wie http://haxe.org/ anschauen. Haxe beinhaltet einen cross-compiler, mit dem du eine Sprache sowohl für server als auch client nutzen kannst.