Homepage von Basti1012 = ,Hauptmenü
Hier im Forum bekommt ihr bei euren fragen schnelle hilfe.Hier geht es rund um das Web SeitenProgrammieren.Alles rund ums Javascript,Html,Php,Css und Sql.Auf fast allen Fragen haben wir eine Antwort.
Der Soforthilfe-chat verspricht das ,was sein Name sagt. Hier sind Leute Online die sofort ihre hilfe anbieten.Seht in der OnlineListe nach und wenn einer Online ist werdet ihr auch antwort bekommen. Admine ,Moderatoren und Helfer sind unsere Spezialisten in Sachen Web Programierung


Die Google-Suche braucht aktuelle Informationen, um sie zu zeigen. (Foto: Evan Lorne/Shutterstock)

Google bringt neue Eigenschaften, um Veranstaltern zu ermöglichen, Suchende schnell über den Status eines Events zu informieren. Das ist besonders in diesen dynamischen Corona-Zeiten nützlich.

Damit Google den aktuellen Status eines Events anzeigen kann, muss der Suchmaschinenriese diesen kennen. Über neue Eigenschaften aus Schema.org 7 können Seitenbetreiber Google dieses Wissen vermitteln.

Die dafür benötigten Eigenschaften sind Teil des erweiterten Vokabulars aus Schema.org 7, das erst am vergangenen Montag veröffentlicht wurde. Um Entwicklern die Verwendung zu erleichtern, hat Google die neuen Eigenschaften in seine Entwickler-Dokumentation aufgenommen. Sie stehen in allen Sprachen und Weltregionen bereit.

So zeigt ihr Google den Event-Status

Dabei ist die Verwendung sehr einfach. Wenn ihr also Google einen Status zu einer Veranstaltung nennen wollt, dann verwendet ihr hierfür die Eigenschaft eventStatus. Habt ihr die Veranstaltung abgesagt, gebt ihr der Eigenschaft den Wert EventCancelled. Dabei behaltet ihr den Wert für startDate auf dem Datum der ursprünglichen Planung.

Ist das Event ohne konkretes Ausweichdatum verschoben, dann setzt ihr den eventStatus auf EventPostponed. Das Start-Datum bleibt bestehen. Erst wenn das neue Datum feststeht, ändert ihr den eventStatus auf EventRescheduled, sowie startDate und endDate auf die neuen Daten.

Habt ihr ein Event von Präsenzveranstaltung zu Online-Event geändert, setzt ihr den eventStatus auf EventMovedOnline. Bei neuen Veranstaltungen, die ihr von vornherein als Online-Veranstaltung geplant habt, könnt ihr zusätzlich die Ortsangabe auf VirtualLocation und den Präsenz-Typ eventAttendanceMode auf OnlineEventAttendanceMode setzen.

Wenn alle Eigenschaften korrekt gesetzt sind, muss Google noch über die Änderungen in Kenntnis gesetzt werden. Das geschieht am sinnvollsten über die Bereitstellung einer automatisierten Sitemap über euren Webserver. Damit überzeugt ihr Google am zuverlässigsten von der Notwendigkeit einer Reindexierung.

Passend dazu: Strukturierte Daten: Google berücksichtigt data-vocabulary.org künftig nicht mehr



MySQL Storage Engine Vergleich – Warum MyISAM?

Neuerdings ist InnoDB die Standard-Engine von MySQL, was ich echt vernünftig finde. Ich finde es erstaunlich, wie sich MyISAM so lange halten konnte und würde gern verstehen, warum. Meiner Meinung nach zeichnet die Verbreitung von MyISAM ein trauriges Bild für Webanwendungen im Allgemeinen. Foreign Keys sind ein Segen! Deshalb die gewagte Aussage: Webanwendungen werden oft als wilder Hack hingeschustert, weswegen auch auf Datenbankseite keine vernünftige Integrität gebraucht wird.

Anders kann ich mir jedenfalls nicht erklären, wie es MyISAM zu solch einer hohen Verbreitung geschafft hat. Nachfolgend führe ich nochmal eine kleine (von mir kommentierte) Gegenüberstellung auf, die die wichtigsten Unterscheidungsmerkmale umfasst:

MyISAM

  • Die Daten-Speicherung in little endian soll für eine Maschinenunabhängigkeit / Betriebssystemunabhängigkeit sorgen – Ich weiß nicht, in wiefern das im Webumfeld praxisrelevant ist (LAMP als Standard-Stack). Kommentare hierzu erwünscht!
  • NULL-Werte sind in indizierten Spalten zulässig
  • MyISAM unterstützt FULLTEXT-Indizes, Blobs und Text-Columns sind indizierbar – Praktisch!
  • Die Höchstlänge für Schlüssel beträgt 1000 Bytes (kann aber durch ein rekompilieren beliebig angepasst werden)
  • eine MyISAM-Tabelle kann maximal 64 Indizes haben – sollte reichen, wer mehr braucht hat oft beim Design was falsch gemacht.
  • Pro Index dürfen es bis zu 16 Spalten sein
  • Jede Tabelle wird getrennt gespeichert: Das Manual sagt dazu:

    Jede MyISAM-Tabelle wird in drei Dateien auf der Festplatte gespeichert. Die Namen der Dateien beginnen mit dem Tabellennamen und haben eine Erweiterung, die den Dateityp angibt. Eine .frm-Datei speichert das Tabellenformat. Die Datendatei besitzt die Erweiterung .MYD (MYData). Die Indexdatei hat die Erweiterung .MYI (MYIndex).

  • Wohl das wichtigste Unterscheidungsmerkmal: MyISAM arbeitet mit Table-Locking. Das ist beim Lesen schneller als das Row-Locking von InnoDB, wird aber bei parallelen Reads/Writes die Schreibvorgänge verzögern. Siehe dazu: Erzeuger-Verbraucher-Problem.

InnoDB

  • Man liest – verglichen mit MyISAM – oft von einer sichereren Recovery im Fall eines Crashes
  • Referentielle Integrität durch Foreign-Key-Unterstützung. Für mich DAS Feature.
  • Transaktionen. In ernstgemeinten, kritischen Anwendungen geht es nicht ohne.
  • Das Manual sagt zur Serverauslastung:

    InnoDB has been designed for maximum performance when processing large data volumes. Its CPU efficiency is probably not matched by any other disk-based relational database engine.

Vielleicht habe ich ein Killer-Argument für MyISAM übersehen? Und was spricht eigentlich gegen eine gemischte Verwendung von MyISAM / InnoDB in der selben Datenbank je nach jeweiliger Anforderung an eine Tabelle?

Umwetter Warnumgen und Wetter vorschau