Ankündigung

Einklappen
Keine Ankündigung bisher.

Eure Meinung.. Macht ein 'DB-Design best practice Guide' Sinn?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Eure Meinung.. Macht ein 'DB-Design best practice Guide' Sinn?

    Hallo,

    was meint ihr, macht sowas Sinn. Gedacht als Stichwort überblick für Einsteiger die noch nichts mit Datenbanken am Hut hatten, was man beim DB-Design beachten sollte.

    Das könnte dann dazu dienen jemanden das vorweg zum Bedenken zeigen zu können, oder auch wenn es jemand schon falsch hat zur Verlinkung was wir denn genau meinen.. So meine Gedanken. Ich hätte dazu grob mal folgende Auflistung:


    - "DB ist kein Excel"
    Normalisierung, Normalformen -> Verlinkung zu Kropff, Wikipedia, und sqldocu

    - Nummerierte Spalten vemeiden / zumeist Hinweis auf Fehldesign

    - Tabellennamen .. in Englisch, nur Kleinbuchstaben und underline verwenden

    - Aliase nutzen

    - Indizies ( inkl. FKs constraints) richtig setzen..

    - "SELECT * vermeiden" könnte dann auch einfliessen

    - GROUP BY.. alle im SELECT Felder müssen grupppiert oder aggregiert sein

    ...

    ?
    The string "()()" is not palindrom but the String "())(" is.

    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
    PHP.de Wissenssammlung | Kein Support per PN

  • #2
    Meine Meinung: Auf jeden Fall, jedoch mit Index, so dass man auf die entsprechenden Unterthemen direkt verlinken kann.

    Kommentar


    • #3
      Hätte es jedenfalls eher "kurz und knackig" je Punkt gehalten, sonst liest das wieder niemand.. Vom Prinzip so in der Art wie die "Code Smells" .. vom Aufbau her. https://php-de.github.io/jumpto/code-smells/
      The string "()()" is not palindrom but the String "())(" is.

      Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
      PHP.de Wissenssammlung | Kein Support per PN

      Kommentar


      • #4
        Ja klar, aber da steht ja am Anfang auch ein Index.
        Zum Beispiel:
        Tabellennamen
        Durchnummerierte Spalten
        usw.

        Kommentar


        • #5
          Hallo,

          würde schon Sinn machen. Würde das aber nicht nur auf relationale Datenbanken beschränken, auch NoSQL ist heute ein großes Thema. Würde da z. B. aus dem Sektor Neo4J, Elesaticsearch und MongoDB beschreiben, dann hat man denke ich alle NoSQL Variationen abgedeckt. Gerade Anfänger sollte man damit eine Entscheidungshilfe mitgeben, ob es der klassische Ansatz mit einer relationalen Datenbank oder eher der new school Ansatz mit NoSQL fürs nächste Projekt wird.


          MFG

          derwunner

          Kommentar


          • #6
            Spontan einige Gedanken:
            • Ich glaube, dass der „es liest keiner, wenn es zu lang ist“-Punkt sehr zentral ist. Allgemein halte ich deshalb die FAQ-Seite (und meinetwegen auch die Code-Smells-Seite, weil sie so ähnlich ist) für die mit Abstand wichtigste Seite in der Sammlung.
              • (Als ich selbst damals meine Variante einer Wissens-Datenbank konzipiert hatte (die auch auf Partizipation ausgelegt war), bin ich auch irgendwann an dem Punkt angelangt, gar nicht so sehr längere Texte aufzunehmen (das kann man qualitativ nicht leisten, ein gepflegtes Linkverzeichnis zu Drittseiten wäre vermutlich besser), sondern möglichst prägnant zu einzelnen Themen zu schreiben. Uralte Beispiele/Umrisse dafür sind derzeit noch hier online: Kontextwechsel, EVA-Prinzip. Es ist leider – zumindest für mich – sehr schwierig, so was zu schreiben, ohne sich früher oder später doch wieder zu verzetteln. Kontextwechsel sind zum Beispiel kein so ganz einfaches Thema. SELFHTML schafft das bekanntlich auch nicht kurz. Allgemein geht die Idee auch in die Richtung der Standardantworten von phpforum.de. Meine Idee ist es seit Jahren, ein Repository solcher Texte zu haben, das jeder überall hosten kann. php-de.github.io ist auch so angelegt. Das gesamte Projekt ist trivial auf eigenem Webspace hostbar. (Fragt mich, wenn ihr es hosten wollt. Man kann es simpel mit Jekyll bauen, ich stelle aber auch gern ein fertiges Archiv bereit. Das sind alles HTML-Dateien.) Ich habe beispielsweise eine Version laufen: http://phpwissen.ermshaus.org/ Da wir in der Community quasi keine Ressourcen haben, was Autoren angeht, und weil auch phpforum.de das Foren-Wiki lieber loswerden würde (hier ist es ja schon weg), erscheint mir das noch immer der beste Ansatz zu sein. Ein gepflegtes Linkverzeichnis war dazu auch was, das nikosch immer wollte. Das ist aber alles nicht so einfach. Ein Aspekt ist auch, dass Suchmaschinen im Grunde in die gleiche Richtung gehen, ein Linkverzeichnis zu sein.)
            • „DB ist kein Excel.“ Stimmt von der Idee her, und es ist auch klar, wie es gemeint ist. Aber am Rande erwähnt: Wir können alle lediglich nicht Excel richtig bedienen. Normalisierung ist natürlich ein wichtiges Thema bei Datenbanken. Datenbanken haben nur leider auch die unpraktische Angewohnheit, relativ kompliziert und irgendwie auch fallbezogen zu sein. Mit Normalisierung ist es ein wenig wie mit OOP. Man könnte beliebig abstrahieren und Dinge unterteilen und als eigene Objekte/Entitäten aufdröseln, aber das ergibt problem- und domänenbezogen nicht immer unbedingt Sinn. Ich arbeite beispielsweise in letzter Zeit viel mit einem System, in dem JSON-Strukturen in einem DB-Feld abgelegt werden. Die Inhalte der JSON-Strukturen könnte man prinzipiell relational als DB-Entitäten normalisieren, aber das wäre im Rahmen dessen, was modelliert wird, völlig übertrieben. Das geht in der Hinsicht eher in Richtung dokumentenbasiertes DBMS, obwohl es ein relationales System ist. Ich will es nicht pauschalisieren oder sagen, dass Normalisierung keine gute Idee ist, aber es ist teilweise durchaus ein Trade-Off mit Komplexität. Andererseits gibt es da schon auch klassische Fehler. Also auf nem „wir setzen mal einen Link“-Level zu Normalisierung: Okay, ja.
            • Peter Kropff… Alle Achtung vor der Leistung. Es gibt nicht viele Leute, die so umfassende Tutorials frei verfügbar anbieten. Seinen Stil muss man aber leider wirklich mögen. Ich tue es nicht. Ich kann das nicht lesen. Mir ist das zu zotig. Ich habe ansonsten zu einer potenziellen anderen Quelle auf GitHub zu php-de.github.io neulich schon was verlinkt: Es gibt zum Beispiel auch eine Menge Sachen bei Wikibooks, die bei uns relativ unter dem Radar laufen. Zumindest bei mir. Zu SQL beispielsweise: https://de.wikibooks.org/wiki/Einf%C...ltsverzeichnis Ich habe nichts davon gelesen. Deren Lizenzen sind anscheinend auch okay (CC-BY-SA wie bei php-de.github.io). Da wäre dann wieder die Frage, inwieweit man ohnehin dünn gestreute Autoren-Ressourcen noch aufsplitten muss. Wahrscheinlich wäre es nicht zu verkehrt, einfach einen Link zu setzen. Siehe dazu den ersten Punkt dieses Posts.
            • Was hausl ansonsten in #1 aufzählt, erscheint mir für überschaubare FAQ-Einträge oder best practices weitestgehend gut geeignet. Um es noch mal zu sagen: Ich glaube, dass es auch absolut sinnvoll ist, in die Richtung FAQs/Standardantworten zu gehen und nicht unbedingt zu versuchen, alles zu erklären. Wobei auch hier wieder eine Pointe ist, dass es früher so was mal gab: http://www.php-faq.de/ Manchmal denke ich, dass wir eher Wissen verlieren als gewinnen.


            (PS: Letztlich noch kritisch angemerkt: Trotz des verhältnismäßig dezentralen Ansatzes (jeder kann es hosten, siehe oben), ist php-de.github.io in gewisser Weise ein Versuch einer Zentralisierung. Das gilt weniger für FAQ-Einträge, aber es gilt für die Artikel. Ich weiß nicht, ob das gut ist. Einerseits ist eine verlässliche Anlaufstelle, bei der man halbwegs die Qualität einschätzen kann, natürlich schön. Andererseits ist die Qualität und die Aktualität der Inhalte auf php-de.github.io aber leider auch ziemlich schwankend. Dazu gibt es eben einige Beispiele für derlei Gemeinschaftswerke, die uns im Laufe der Zeit mehr oder weniger weggebrochen sind oder die eingeschlafen sind. (Jedes Forum hatte zu einem Zeitpunkt mal ein Wiki.) An php-de.github.io schreibt auch seit einiger Zeit niemand außer hausl wirklich rum, wenn ich das richtig beobachtet habe. Ich repariere auch nur manchmal ein paar Kommas und achte darauf, dass alles hübsch selbst-hostbar bleibt. Letztlich ist es schon so, dass es kaum Zusammenarbeit gibt, was die inhaltliche Arbeit angeht. Jeder Artikel wurde mehr oder weniger von einer Person geschrieben (die meisten wohl noch immer von nikosch, denke ich). Das meine ich aber überhaupt nicht negativ. Dass es ein öffentliches Repo ist, an dem jeder teilnehmen kann, hat trotzdem Vorteile, weil sich so kleinere Sachen reparieren oder berichtigen lassen. Dennoch stellt sich mir dabei schon immer wieder mal die Frage, ob es wirklich so notwendig ist, all die Informationen an einer zentralen Stelle zusammenzutragen (Wikipedia-Style) oder ob es nicht genauso gut oder besser wäre, wenn jeder seinen Content selbst hosten würde (Web-Style).)

            Kommentar


            • #7
              Wenn der Text ordentlich Strukturiert ist und sich flüssig liest, ohne das ich die neusten und coolsten Hype-Begriffe nachschlagen muss, dann ist mir ein umfassendes und ausführliches Werk immer lieber als ein zu kurz gekommenes. Das Internet hat genug Speicher für gute Information, und wer keine Zeit hat mal was durchzulesen, der ist es nicht wert sich Entwickler zu nennen.
              Ich bin eher froh über jugend und kiddiefreie Sprache, dezenten Humor, Anglizismenarm und Analogiereich, gehaltvoll an Plastizität und mit Beispielen geschmückt, wo man merkt, das der Autor die tatsächlich mal ausprobiert hat.
              bitcoin.de <- Meine Freelancerwährung

              Kommentar


              • #8
                Ich glaube, dass es einen sweet spot gibt, Problembewusstsein für ein Thema hervorzurufen, ohne zu knapp zu antworten und ohne gleich zu verlangen, dass Leute 3000 Wörter lesen. Es ist eben häufig so, dass es bei Hinweisen um Themen geht, die nicht unmittelbar was mit dem konkreten aktuellen Problem des Fragestellers zu tun haben. Ich glaube, dass es hilft, das zu respektieren. Das Ziel sollte es sein, dem Fragesteller kurz zu erklären, wieso es sinnvoll wäre, einen bestimmten Aspekt anzugehen. Das ist schwierig.

                Als positives Beispiel eine Standardantwort von phpforum.de:

                Im gezeigten Code wird der Kontextwechsel nach HTML nicht korrekt behandelt. Dadurch könnten die für HTML syntaktisch relevanten Zeichen (&, ", ', <, >) an ungewollten Stellen in die Ausgabe geschrieben werden. Dies kann zu fehlerhaftem HTML-Code, zu falscher Darstellung oder Fehlfunktion der Webseite und zu Sicherheitsproblemen führen.

                Im Zuge korrekter Programmierung müssen Werte, die von PHP aus in HTML-Code eingefügt werden, vor der Ausgabe escapet werden, wodurch die syntaktisch relevanten Zeichen in HTML-Entities umgewandelt werden. Dazu dient in PHP die Funktion htmlspecialchars oder gegebenenfalls eine entsprechende Methode eines genutzten Frameworks oder einer genutzten Template-Engine.

                PHP-Code:
                <?php
                $title 
                'Infos zu HTML-Tags: <h1>, <a> & Co.';
                $url   'http://example.org/?foo=1&bar=2';
                ?>

                <h1><?=htmlspecialchars($titleENT_QUOTES'UTF-8')?></h1>
                <p><a href="<?=htmlspecialchars($urlENT_QUOTES'UTF-8')?>">Link</a></p>
                (Quelle) (Die wurde von mir eingestellt, an der genauen Formulierung haben aber weitere Personen mitgewirkt.)

                Vergleich das mit Antworten wie „Dein Code ist anfällig für Cross-Site-Scripting-Attacken“ oder „Dein Code beachtet Kontextwechsel nicht. Bitte beachten: http://wiki.selfhtml.org/wiki/PHP/An...textwechsel“.

                Wobei auch ein Hinweis in der zuletzt vorgestellten Form besser ist als gar kein Hinweis.

                Kommentar


                • #9
                  mermshaus Dein Engagement in allen Ehren, aber ich verstehe nicht so ganz, wie Deine letzten Antworten noch mit dem Ausgangsthema zu tun haben. Du beschreibst doch eher allgemeine Probleme mit einer Wissenssammlung, als auf die hier beschriebene Meinungsumfrage zu einer Wissenssammlung-Ergänzung in Sachen "DB-Design best practice Guide" einzugehen.

                  Kommentar


                  • #10
                    (Ich habe meinen langen Beitrag noch etwas formatiert, um die allgemeinen Aspekte in den Hintergrund zu rücken. Der Beitrag wirkte vielleicht etwas „technisch“, und es ist sicherlich richtig, dass ich da gewisse Ansichten habe. Andererseits ist das, was ich schreibe, aber auch nicht einfach so aus der Luft gegriffen. Letztlich wollen wir ja erreichen, dass die Leser was mitnehmen und dass die Geschichte einen Sinn hat. Da ist die Aufbereitung schon wichtig.)

                    Kommentar

                    Lädt...
                    X