Beliebig viele Tabellen nebeneinander darstellen

[Pit]

Hallo,

ich möchte beliebig viele Tabellen nebeneinander darstellen können. Wenn der Viewport dafür nicht ausreicht, möchte ich horizontal scrollen.

1. Möglichkeit: Alle Tabellen in eine Tabelle packen?
2. Möglichkeit: Mit float und overflow?

Ehrlich gesagt, ich weiß nicht, wie ich das am besten angehe.

Kann mir jemand helfen?

Pit

[Matthias Apsel]

Hallo Pit,

ich möchte beliebig viele Tabellen nebeneinander darstellen können.

Bedenke, dass Tabellen ausschließlich für tabellarische Daten gedacht sind.

1. Möglichkeit: Alle Tabellen in eine Tabelle packen?

Nein, denn Tabellen sind keine tabellarischen Daten.

Ehrlich gesagt, ich weiß nicht, wie ich das am besten angehe.

body {
    white-space: nowrap;
    /* Falls body der umgebende Container ist */
}

table {
    display: inline-table;
}

Bis demnächst
Matthias

[TS]

Hello,

Nein, denn Tabellen sind keine tabellarischen Daten.

Das kommt doch auf den Inhalt an!

Wenn ich Monatsübersichten für mehrere Jahre erzeuge und die dann in den Dimensionen "Jahr" und "Monat" darstellen will, ergeben die einzelnen Tabellen durchaus wieder Zellen einer größeren Tabelle.

Ob diese Darstellungsart aber geschickt ist, steht auf einem anderen Blatt.

Liebe Grüße
Tom S.

[Matthias Apsel]

Hallo TS,

Nein, denn Tabellen sind keine tabellarischen Daten.

Das kommt doch auf den Inhalt an!

Wenn ich Monatsübersichten für mehrere Jahre erzeuge und die dann in den Dimensionen "Jahr" und "Monat" darstellen will, ergeben die einzelnen Tabellen durchaus wieder Zellen einer größeren Tabelle.

Gutes Beispiel.

Bis demnächst
Matthias

[Pit]

Hallo zusammen,

es geht um einen Terminplaner, bei dem ich jede Woche in eine Tabelle packe.

Nun soll der User sich bei Bedarf auch mal 2 oder 4 Wochen nebeneinander darstellen lassen dürfen.

Pit

[Pit]

Hi,

erstmal danke, Tabellendarstellu ng nebeneinander funktioniert hervorragend.

Noch eine Frage zum Füllen der Tabellen mit Terminen aus der db:

Was ist da am performantesten:

• Je Tag eine mysql-Abfrage und dann per php in die Tabellenzellen einfügen
• Alle Daten mit mysql abrufen, die Arrays so zubereiten, wie benötigt und die Tabellenzellen per php füllen
• Alle Daten mit mysql abrufen, die Arrays so zubereiten, wie benötigt und die Tabellenzellen clientseitig per Jquery füllen ?

Pit

[Rolf B]

Hallo Pit,

beantworten kann man diese Frage letztlich nur mit Lasttests, weil die Antwort sehr von den Umständen abhängt. Es gibt aber ein paar Design-Maximen, wenn man solche Architekturen plant.

Bei der Planung von Kommunikation zwischen verteilten Systemen lautet das Motto stets: Be Chunky, Not Chatty. Heißt: Ein großer Datenblock ist besser als mehrere kleine, weil damit der Overhead für die Kommunikation nur einmal anfällt. Die Verteilung bei Dir ist: Browser - Web-Server - DB-Server. Die Strecke Browser-Webserver ist teuer (weil über Internet), die Streche Webserver - DB-Server relativ billig (weil das oft der gleiche Server ist, das erkennst Du daran ob dein Hostname für die DB-Connection "localhost" ist.) Bei einer billigen Kommunikationsstrecke kannst Du Dir etwas Chattiness erlauben.

Bei der Planung von DB-Zugriffen lautet die Maxime: Index-Seek ist besser als Index-Scan, und Index-Scan ist besser als Table-Scan. Was genau passiert, sagt Dir die Explain-Funktion der Datenbank. Wenn deine Abfrage für einen Tag per Index-Seek funktioniert, und eine Abfrage für viele Tage zu einem Index- oder Table-Scan führt, dann überlege Dir, wie Du die DB zu einem günstigeren Verhalten bewegen kannst.

Einfluss auf die Performance hat auch, ob Du das SQL Statements für die Kalenderabfrage einmal mit PREPARE an den Server schickst und dann mit unterschiedlichen Daten aufrufst, oder ob Du jedesmal einen neuen SQL String zusammenzimmerst.

Das Thema "Index-Seek vs Table-Scan" hatte ich letzte Woche noch im Beruf - da lautete der Auftrag, eine Art "reverse Like" zu bauen, d.h. die Sätze in der DB zu finden, wo der Wert eines variabel langen DB-Feldes dem Anfang meines Suchbegriffs entsprach (=finde den Vorwahl-Teil einer Telefonnummer). Die "stupide" Abfrage war ein WHERE SUBSTRING(Telefonnummer,1,LEN(Vorwahl)) = Vorwahl - das funktioniert, erzeugt aber einen Table-Scan. Statt dessen habe ich dann geschaut, welche Vorwahllängen es in D gibt (2 - 5) und vier SELECT gemacht, von denen jeder eine Länge prüfte, und diese mit UNION ALL verkettet. Damit hatte ich 4 Index-Seeks statt einem Table-Scan und der Laufzeit-Unterschied war dramatisch. D.h. ich habe eine bestimmte Eigenschaft meiner Daten genutzt, um eine bessere Query zu erhalten.

Es kann auch passieren, dass der SQL Server entscheidet, einen Index nicht zu verwenden und lieber einen Table-Scan macht, weil er den Overhead für die Indexsuche für zu groß hält. Meistens hat er da recht - aber es kann dann auch sein, dass dein Index ungünstig ist.

Die Frage, ob Du eine oder mehrere SQL Abfragen machen sollst, hängt also zum einen davon ab, ob dein SQL Server unter localhost erreicht wird, und zum anderen, ob du die Abfrage für alle Tage mit einer index-gestützten Abfrage hinbekommst.

Die Frage, WO man eine Verarbeitung durchführt, ist dagegen schwieriger zu beantworten. Aus Sicht des Webserver-Betreibers ist es besser, wenn der Browser das HTML aus einer kompakten Datenlieferung generiert - der Webserver hat dann einfach weniger zu tun. Wenn das clientseitige JavaScript gut gemacht ist, kann das unterm Strich eine brauchbare Performance ergeben. Wenn es schlecht gemacht ist, ist es mies für den User, weil der Seitenaufbau dann zu lange dauert. Wenn dein Server nicht ausgelastet ist, ist ein HTML-Rendering mit PHP unterm Strich wohl am schnellsten. Wenn dein Server auf dem letzten Loch pfeift, kannst Du mit einer Auslagerung der HTML-Erzeugung auf den Client eine Verbesserung erreichen. Es stellt sich auch die Frage: Wie fit bist Du in PHP? Wie fit bist Du in JavaScript? Mit welcher Sprache, auf welcher Plattform erreichst Du Dein Ziel, ohne erstmal eine vergletscherte Lernkurve zu überwinden.

Was ich persönlich anstreben würde? Nr. 2 oder Nr. 3, abhängig von der Auslastung des Webservers. Es gibt auch Fälle, wo Nr. 1 sinnvoll sein kann. Nämlich dann, wenn es auf dem Webserver sowohl an CPU als auch an Speicher knapp ist. Dann kannst Du eine HTML-Seite ausliefern, die nur den Rahmen enthält, und die holt sich per AJAX dann die einzelnen Tage nach. Damit ersetzt Du einen großen Request durch mehrere kleine. Wenn Du bspw. einen Webserver-Cluster hast (der am Anschlag ist), dann verteilt sich so die Last besser. Ob Du in einer solchen Situation bist, kannst nur Du wissen.

Rolf

[Matthias Apsel]

Hallo Rolf B,

Statt dessen habe ich dann geschaut, welche Vorwahllängen es in D gibt (2 - 5)

falls man die führende Null nicht berücksichtigt.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Klugschiss: Vorwahl = Verkehrsausscheidungsziffer + Ortnetzkennzahl

Beispiel Berlin: "030" = "0" + "30"

LLAP 🖖

[Pit]

Hallo RolfB,

was für eine umfassende und nachvollziehbare Antwort. Herzlichsten Dank dafür.

Ich habe sowas vor einiger Zeit mal für ein anderes Projekt gemacht, das aber auch noch wechselseitig Daten hin und her manipulieren mußte. Da hatte ich mich für Lösung3 entschieden. Läuft megaschnell, war aber ausgesprochen kompliziert in der Programmierung, weil man permanent zwischen Front- und Backend hin und her schiebt.

Eigentlich hast Du zum Thema al,les gesagt, eines würde ich noch hinzufügen:

Die Streche Webserver - DB-Server muß nicht zwingend für alle Zeiten dieselbe bleiben. Daher widerstrebt mir so ein bischen, mich auf die Geschwindigkeit derselbe zu verlassen.

Ich glaube, im Moment tendiere ich dazu, dem Webserver die Hauptlast aufzutragen, also Lösung2.

Danke für Deine Hilfe bei der Findung der Lösung.

Pit