Beiträge von Nathalie0hneHerz

    aber manchen kommt es auch auf Kompatibilität mit älteren Browsern an und da macht flexbox dann doch ein paar Probleme.

    Das finde ich dann doch etwas übertrieben, wenn sogar der Opera Mini da mitmacht, kann man sich da doch eigentlich sehr sicher sein:




    Wer aufgrund von Kompatibilität auf FlexBox verzichtet, setzt ein falsches Maß an.

    In Netty hat sich da ein anderes Pattern auch noch sehr bewährt, das mehr der ursprünglichen Idee von Netty in die Hände spielt: Das Hinzufügen und entfernen von Handlern in der Pipeline. Das bedeutet dass man am Anfang eine Pipeline hat, die eigentlich nur aus einem "LoginHandler" besteht (Features wie Length fields etc. zur Vereinfachung des Modells weggelassen). In diesem "LoginHandler" wird bei reinkommenden Daten darauf gecheckt, ob es sich um eine Authentifizierung handelt. Wenn dem nicht so ist, wird das Paket einfach fallen gelassen und nicht weiter beachtet. Wenn es eine valide Authentifizierung gibt, entfernt sich der LoginHandler selbst aus der Pipeline und fügt einen Handler für das eigentliche Protokoll hinzu.

    LeL du hattest recht der Dev hat echt keinen Schimmer xD
    wozu ne id UND UUID (universally unique identifier) was schon eine id in sich selbst ist :D

    Nun ja das beiseite habt ihr doch den Namen und die UUID also verstehe ich das ursprüngliche Problem nicht?

    Lel ich hatte recht, du hast echt keinen Schimmer xD


    Grundsätzlich mag einem diese Idee kommen, abwegig wäre es eher weniger, eine UUID als Primary Key zu verwenden. Man hat dadurch sogar einige Vorteile, das kann man nicht abstreiten. Durch UUIDs sind nicht nur einzelne Tupel innerhalb einer Tabelle, sondern sogar mehr oder weniger global (Zwischen Tabellen, Servern, Clustern...) einzigartig. Allerdings sind die UUIDs ein äußerst zweischneidiges Schwert, wobei die falsche Seite die schärfere ist. Es hat schon einen Grund dass Integers / Longs normalerweise als PRimary Key dienen. Sie sind sehr klein, leicht zu indexen und generell sind sie einfacher zu handhaben. Ein paar offentsichtliche Nachteile ist der Verlust der Sortierung nach Erstellung o.ä.


    Bei UUIDs fängt es schon damit an, dass man nachdenken muss, ob man sie als VARCHAR oder in binärer Form abspeichert. Dann sollte man folgendes bedenken:

    1. Indexing ist dadurch deutlich komplexer, die eindeutige Identifizierung braucht mehr Ressourcen
    2. Joins auf ggf. Chars / größere Datentypen sind inperformanter als auf einen Integer / Long oder ähnliche atomare und leichtgewichtige Datentypen
    3. So banal es ist, Integer Ids kann man sich beim arbeiten mit Daten merken, UUIDs sind in der Handhabung dann immer etwas klobiger


    Man muss etwas überlegen, es gibt sehr viele Überlegungen, mehr will ich net sagen. Jemanden direkt als etwas doof hinzustellen ist da schon etwas vorschnell geschossen.

    Natürlich wäre selbst machen eine Option. Aber ist das an dieser Stelle sinnvoll? Um das System hinter ProtocolLib zu verstehen ist es natürlich schön sich eine eigene Lösung zu basteln, um daran zu lernen. Man kann aus akademischen Gründen so ziemlich schreiben und nicht schreiben, was man will. Aber wenn du dann ein echtes Produkt entwickeln willst, das im Produktivbetrieb arbeiten soll, dann setzt man meistens besser auf etablierte, stabile und gut supportete Lösungen, die man dann eventuell auch einem Kunden verkaufen kann. Mach ruhig deinen ProtocolLib Klon und probier aus ob er funktioniert. Aber sobald du deine Software produktiv nutzen willst, geh auf Nummer sicher und nutz ProtocolLib, allein schon weil du dessen Funktionsumfang und Essenz nicht in allzu kurzer Zeit so replizieren kannst, dass es im Produktivbetrieb Sinn macht.

    Zitat

    Ich gebe dir ja recht, jedoch ist es eine Möglichkeit und mehr auch nicht.

    Klar kann man das machen, aber man kann ja auch AFD wählen



    So wie Nathalie0hneHerz die Gadgets bekommt, musst du aber alle (möglicherweise 1mio Einträge) durchgehen, und wie ein Idiot mit while-Schleifen arbeiten...

    Und deine Methode ist da inwiefern besser? Du musst auch nach deiner Auffassung alle Einträge durchgehen. Und zu deinem Gemecker über while Schleifen:


    Du:


    Ich:

    Java
    ResultSet result;
    List<Integer> gadgetIds;
    
    while (result.next()) {
        gadgetIds.add(result.getInt("gadgetId"));
    }
    
    return gadgetIds;


    Was hattest du noch gleich mit Idiot gesagt?


    Im end Effekt kommt's aufs gleiche, man bekommt eine Liste zurück welche Gadgets man besitzt.

    Trivial, was soll auch sonst kommen? Das ist der Sinn der Datenhaltungsschicht und kein Argument oder so.



    Und jain. Ich hätte die Daten in einer Liste gespeichert und erst bei Serverquit wieder (wie du gesagt hast, in einem String aktualisiert)

    Tut auch nix zur Sache und ändert nichts an deinem Datenmodell.

    Nicht ganz so Lg

    Nein Nein Nein NEIN NEEEEIN! Mit so etwas fangen wir erst gar nicht an. Das verstößt gegen so ziemlich alles wofür MySQL steht. Das ist schlicht und einfach eine Katastrophe. Auf so ein Nicht-Datenmodel, ich weigere mich es Datenmodell zu nennen, sind kaum noch Datenoperationen möglich, das ist kompletter Unsinn um nicht zu sagen Bullshit. Wenn man versucht in deinem Datenmodell etwas zu verändern bricht man sich ja die Finger.


    Die Sache mit dem enum kann man ja machen, aber der ganze Rest ist next level Bullshit. Wie soll das denn elegant funktionieren? Wie fügst du neue Gadgets hinzu, entfernst alte, oder lässt welche ganz verschwinden? Holst du dir jedes mal den ganzen String, splittest den auf, fängst dann an auf dem Array aus Ints rumzuklopppen, fügst das wieder zusammen und speicherst es dann wieder. Um auf mein Beispiel oben zurückzukommen:


    Neues Gadget zu Spieler hinzufügen (Syntax/Semantik nicht korrekt, nur zur Verdeutlichung):

    INSERT INTO purchased_gadgets (playerUniqueId, gadgetId) VALUES (1f32ea66-29a5-4b8e-9d7b-354782c4dbc1,1)


    Gadget entfernen:

    DELETE FROM purchased_gadgets WHERE playerUniqueId = 1f32ea66-29a5-4b8e-9d7b-354782c4dbc1 AND gadgetId = 1

    Alle Gadgets eines Spielers:

    SELECT gadgetId FROM purchased_gadgets WHERE playerUniqueId = 1f32ea66-29a5-4b8e-9d7b-354782c4dbc1


    Ich will mir gar nicht ausmalen wie das bei dir aussehen würde. Es ist einfach grober Unfug und ich halte jeden an, so etwas was AgroLegacy vorschlägt niemals zu machen. Es ist kaum wartbar, absolut gegen jede Norm und ihr werdet über kurz oder lang Datensalat haben.

    Wenn Existenz und nicht existenz bereits ein Zustand sind, wieso dann noch einen weitere Zustand? Und die Gadget als Namen zu speichern wäre auch unklug, Namen will man gerne ändern, generell sind Namen bei sowas meistens fehl am Platz. Eine Id ist einfach eleganter.

    Hey,


    anscheinend hast du noch nicht viel mit (MySQL) Datenbanken gearbeitet. Schon dein derzeitiger Ausgangspunkt, dass jedes Gadget eine eigene Spalte bekommt ist in der Wurzel falsch gedacht. Klar kann man das machen, aber man kann ja auch AFD wählen. In deinem Modell müsstest du jedes mal wenn du ein neues Gadget hinzufügst deine Tabelle verändern. Überleg dir mal, was würdest du für eine Query schreiben, um alle Gadgets zu bekommen die ein Spieler besitzt? Du merkst dass dein Modell sehr schnell massive Defizite aufzeigt, sobald man versucht ein paar Datenoperationen durchzuführen. Denk dir dass eine Tabelle immer eine Entität vertritt. Du hast eine Tabelle 'players' für die Spieler, in dieser Tabelle repräsentiert jedes Tupel, repräsentiert durch eine Zeile eine Instanz dieser Entität:


    Code
    +-----+-----------+-----------+----------------+-----------+
    | id  | vorname   | nachname  | herkunftsland  | hautfarbe |
    +-----+-----------+-----------+----------------+-----------+
    |   0 | Gabriele  | Neuer     | Deutschland    | Schnee    |
    |   1 | Ahmet     | Ahbad     | Türkei         | Bisschen  |
    |   2 | Dustin    | Eckert    | USA            | Fettig    |
    +-----+-----------+-----------+----------------+-----------+


    Letzendlich sind das Gaabriele Neuer aus Deutschland mit Haut so weiß wie Schnee, Ahmet Abad aus der Türkei und Dustin Eckert aus den USA. Du möchtest diesen Personen jetzt noch mehr zuordnen. Bei einfachen Eigenschaften, die in sich konsistent sind, sich niemals ändern usw. kannst du eine weitere Splate hinzufügen. Aber sobald diese Eigenschaften komplexer werden fängt das System an zu bröckeln. Wenn du jetzt gaaaaaanz viele Gadgets hast, dann machst du dafür keine neuen Spalten, sondern eine neue Tabelle (Siehe auch https://de.wikipedia.org/wiki/Normalisierung_(Datenbank) und https://de.wikipedia.org/wiki/…4t_(Datenbankmodellierung) (HIER GANZ WICHTIG!)). So kannst du eine einfache skalierbare Modellierung beibehalten. Mein Tipp: Mal dir erstmal ein http://www.datenbanken-versteh…tity-relationship-modell/ ERM um dir einen Überblick zu schaffen.

    Du solltest erstmal ein wenig gedanklich Frontend und Backend trennen. Wenn du an die Datenbank denkst solltest du in der Regel nicht gleichzeitig an deine Datenbank denken. Deine Datenhaltungsschicht sollte so sauber und generisch wie möglich sein. Wenn wir uns nun ansehen, wie denn deine Daten aufgebaut sind merken wir schnell dass wir eine Beziehung (Spieler <=> Gadget) haben. Doch wie bilden wir diese Beziehung ab. Ein Spieler kann mehrere Gadgets haben und ein Gadget kann von mehreren Spielern besessen werden, sodass wir hier von einer n:m Beziehung ausgehen müssen. Das bedeutet eigentlich immer, dass wir uns eine eigene Tabelle dafür zulegen:



    Auch im Sinne der Normallformen haben wir jetzt eine saubere Spieler zu Gadget Relation. Wenn du magst kannst du nun auch noch Metadaten hinzufügen (boughtvia könnte man noch mappen, aber hier gehts um die visualisierung):



    Wie diese Daten dargestellt werden (Inventar, Webseite...) ist erst einmal völlig egal.


    Mit freundlichen Grüßen

    Deine Herrin

    Entweder du strukturierst dein Projekt gut sodass an die Klasse sowieso niemand dran kommt (Sie nicht erzeugen kann / Es nur schwer und sinnlos kann bzw. deine Instanz der Klasse nicht zur Verfügung steht), oder du machst es hacky und dreckig (Um mal kreativ zu sein) und holst dir den Stack Trace des momentanen Threads und checkst ob die aufrufenden Klassen nur von dir sind. Meistens bringt es gutes Design bereits mit, dass der "Nutzer" nichts damit anfangen an.

    Wollt ihr euren Kleinkrieg vielleicht woanders zum Ende bringen? Ich bin sicher ihr habt euch viel zu erzählen, habt auch alle sehr schöne Argumente, aber es geht trotzdem zu wie im Kindergarten

    (*mimimi* du hast aber gesagt *mimimi* du durftest jetzt 5 Minuten auf die Wippe *mimimi* meine Sandburg ist schöner *mimimi* mein bestes Stück ist größer). Verlegt das woanders hin und versucht euch nicht zu zerfleischen, nur weil der eine irgendwann mal was gesagt dass euch nicht 100% in den Kram passt.


    Zum Thema: Die Zeit, solche Sprachen zu lernen kann meiner Meinung nach sinnvoller genutzt werden. Diese "Aliens" von Sprachen, von denen irgendwer meinte sie sei noch nicht perfekt, sind meistens Modeerscheinungen bringen meist genauso viele Probleme mit wie sie zu lösen behaupten. Eine Sprache zu nutzen nur weil Feature 17 da so gut funktioniert ist meistens schon eine sehr kurzsichtige Entscheidung, bei vielen tollen Sachen kann man es sich noch überlegen, aber meistens endet es damit dass man wieder zum Ursprung zurückgeht. Nebenbei ganz nett, darauf konzentrieren vermutlich nicht.