1 up | 2 up | 3 up | 4 up | 5 up | 6 up | 7 up | 8 up | 9 up | 10 up | 11 up | 12 up |
^^^ Additional posts ^^^
zorg.ch
#39712 by @ 27.07.2004 13:35 - nach oben -
ja, da sagt auch niemand etwas anders, tschuder meint das der erste post nachwievor ein post bleibt, wobei dazu ein datensatz in der thread table erstellt wird der dann beschreibt das dieser post ein thread ist.
zorg.ch
#39714 by @ 27.07.2004 13:43 - nach oben -
Ah ok... hmmm wäre auch eine Idee...
zorg.ch
#39718 by @ 27.07.2004 14:05 - nach oben -
wäre glaubs einiges flexibler.
zorg.ch
#39745 by @ 27.07.2004 14:32 - nach oben -
Und nebenbei wärs sauber. Weil ein Thread nunmal ein Thread ist und in die Thread Tabelle gehört. Sowie ein Post ein Post ist und damit in die Post Tabelle gehört.
Ist wie bei einem Verkaufssystem von SAP, dort hats im Kopf des Auftrages nicht auch noch die Informationen der Ersten Position.
zorg.ch
#39753 by @ 27.07.2004 14:43 - nach oben -
Ein Auftrag-Kopf ist auch was völlig anderes als eine Auftragsposition...
zorg.ch
#39756 by @ 27.07.2004 14:44 - nach oben -
Ein Thread ist ja auch was völlig anderes als ein Post.
zorg.ch
#39764 by @ 27.07.2004 14:58 - nach oben -
Nein. Ein Thread sowie ein Post haben beide: eine parent_id, eine userid, ein text, ein datum, und ein board
zorg.ch
#39768 by @ 27.07.2004 15:01 - nach oben -
Knight Rider!
zorg.ch
#39851 by @ 28.07.2004 00:06 - nach oben -
höh?
zorg.ch
#39773 by @ 27.07.2004 15:03 - nach oben -
Was für einen Text hat den der Thread?
Der Thread ist doch nur das Gerüst für die Posts, also hat der selbst kein Text.
Die parrent_id ist IMOH das "Board".
Das restliche Gemüse (Ersteller, Datum) ist natürlich für beide vorhanden.
zorg.ch
#39780 by @ 27.07.2004 15:05 - nach oben -
Ein Thread hat sehr wohl einen Text. (Logisch gesehen.) Nämlicher der Text auf den alle seine Posts antworten.
Board könnte man mit der Parent_id lösen, ja.
zorg.ch
#39786 by @ 27.07.2004 15:10 - nach oben -
klar, aber im thread-datensatz steht nix von text, da steht dann die ID zum post welcher den thread-text darstellt.
Additional posts
zorg.ch
#39771 by @ 27.07.2004 15:01 - nach oben -
Kennst du Braso?

Das ist eine Branchensoftware fuer Elektrounternehmungen. Macht also Auftrags, Lager, etc. pp. Verwaltung fuer uns. Man koennte mit genuegend Aufwand wohl auch SAP fuer den selben Zweck verwenden.

Die Firma hinter dem Spass ist sehr professionell. Das ganze System laeuft folgendermassen:

Server, mit MSSQL Server. Keinerlei Braso-Eigene Software.

Auf den Clients hast du nun deren Software, die dann den ganzen Spass berechnet und auswertet. Bei Teilweise arbeiten sieht die Datenstruktur auf dem Server so aus:

Spalten: id, data
Inhalte: unsigned int, text (durch kommatagetrennte werte)

Will man nun etwas dieser Daten abrufen, macht der Server ein SELECT * FROM table; und der Client parst danach den Inhalt von `data'.

Das ganze performt ueber WAN-Leitungen so gut, das wir dort Windows Terminal Server einsetzen ;)
zorg.ch
#39785 by @ 27.07.2004 15:10 - nach oben -
Ehrlich?? Klingt gar nicht so schön... wobei der Traffic glaub schon klein sein muss...
zorg.ch
#39787 by @ 27.07.2004 15:10 - nach oben -
Das ist aber mehr als ober wüsst.

Soll ich dir verraten wie SAP arbeitet?
Du hast einen Server (mit einer bescheidenen Datenbank wie Oracle, DB2, Ingres, MaxDB, SYBASE) und einen Client.
Der Client ist so was ähnliches wie ein HTML Browser nur das da kein HTML Protokoll drüber läuft sondern n SAP Protokoll das auch n bischen Interaktion versteht.
Da werden bestimmt weniger Daten hin und her geschoben als bei der BRASO.

Der Client dürfte auch etwas schlanker sein als derjenige von BRASO.
Der Server ist sehrwahrscheinlich grösser, aber das spielt eh keine Rolle.
zorg.ch
#39790 by @ 27.07.2004 15:13 - nach oben -
Man könnte hier wohl über die Vor- und Nachteile von Thin- und Fatclients diskutieren... ich denke beides hat sein Anwendungsgebiet...
zorg.ch
#39819 by @ 27.07.2004 16:06 - nach oben -
Sicher kann man darüber diskutieren.
Aber über schönheit von SQL SQL Statements und Tabellen lässt sich nicht diskutieren.