SQL Pro User je eine Tabelle

Julexander

Lieutenant
Registriert
Juli 2004
Beiträge
568
Hi, bin Informatikstudent im 3. Sem und hab jetz 1 Semester Datenbanken hinter mir.
Hab ja jetzt Ferien und da ich mal endlich Zeit habe wollte ich ein kleines Projekt machen.

Ich mache eine kleine Internetapplikation (C#.net) bei der ich meine Bankkonten verwalten kann (CSV Datei exportiert mit allen Operationen) und gucken kann wie viel ich ausgebe und verdiene.
Nun hat jede CSV Datei einige hundert Eintraege, weshalb ich fragen moechte ob es elegant ist fuer jeden User so eine Tabelle mit den Eintraegen zu erstellen, damit nicht alles in einer steht?
Wie gesagt, erst ein Semester hinter mir :) Falls ihr einen Link fuer mich haettet wo ich mich da irgendwie reinlesen kann, waere nett.
 
edit: oh sorry ich hab überlesen das es CSV ist ... dachte bei C# gleich an eine relationale Datenbank die SQL benutzt ... keine ahnung was da am praktikabelsten ist

du willst für jeden user EINE tabelle erstellen?
im realen anwendungsfall hat man dann am ende je nach Userzahl sehr viele Tabellen.

du erstellst eine tabelle für die user
und eine für die daten ...
die daten verknüpfst du dann über einen unique identifier mit den usern aus der user tabelle ...

bsp User Tabelle (Spaltennamen):

guid
vorname
nachname
adresse
email
blablup

bsp. Datentabelle:
id -> jeder datensatz hat seine eigene id
user -> die id vom user aus der user tabelle
usw...
 
Zuletzt bearbeitet:
Ok ja so wollte ich das ja machen weil ichs so gelernt habe nur ich dachte halt mit vielen tausend Usern ist die Tabelle dann Millionen Eintraege lang ^^
Na gut danke
 
millionen zeilen sind für eine DB je nach Software kein Problem. Das hängt dann einfach von einem entsprechend dimensionierten I/O System ab.
 
Ganz wichtig ist dass du deine Indizes gut setzt. Beim Daten Table z.B. einen Index auf die UserID (ich würde in dem Fall übrigens keine GUIDs verwenden). Ich programmiere und betreibe Datenbanken mit Tables wo mehrere hundert Millionen Einträge gespeichert sind, wenn du dann eine Abfrage machst und die entsprechenden Indizes gesetzt sind - dann hat du ein Ergebnis in 0,nix Sekunden!

User-Table: UserID int, Firstname nvarchar(32), Lastname nvarchar(32), ....
Transaction-Table: TransactionID int, UserID int, Moment datetime, amount money, ...

Zwischen Transaction-Table und User-Table setzt du noch eine "Relationship" auf die UserID
Und wie gesagt beim Transaction-Table noch einen Index auf UserID, und vielleicht auf den Moment ...

EDIT: man spricht übrigens von "Relationalen Datenbank" weil zwischen den Tabellen Relationen sind - in unserem Beispiel die UserID.
 
bepi74 schrieb:
Ganz wichtig ist dass du deine Indizes gut setzt. Beim Daten Table z.B. einen Index auf die UserID (ich würde in dem Fall übrigens keine GUIDs verwenden). Ich programmiere und betreibe Datenbanken mit Tables wo mehrere hundert Millionen Einträge gespeichert sind, wenn du dann eine Abfrage machst und die entsprechenden Indizes gesetzt sind - dann hat du ein Ergebnis in 0,nix Sekunden!

User-Table: UserID int, Firstname nvarchar(32), Lastname nvarchar(32), ....
Transaction-Table: TransactionID int, UserID int, Moment datetime, amount money, ...

Zwischen Transaction-Table und User-Table setzt du noch eine "Relationship" auf die UserID
Und wie gesagt beim Transaction-Table noch einen Index auf UserID, und vielleicht auf den Moment ...

EDIT: man spricht übrigens von "Relationalen Datenbank" weil zwischen den Tabellen Relationen sind - in unserem Beispiel die UserID.

Man spricht nicht von "Relationalen Datenbanken" weil zwischen den Tabellen Relationen sind, sondern weil Tabellen Relationen sind (auch im mathematischen Sinne)! Mit Assoziationen hat es absolut gar nichts zu tun.
 
IceMatrix schrieb:
Man spricht nicht von "Relationalen Datenbanken" weil zwischen den Tabellen Relationen sind, sondern weil Tabellen Relationen sind (auch im mathematischen Sinne)! Mit Assoziationen hat es absolut gar nichts zu tun.

siehe da ... da merkt man das ich nicht studiert habe :) hab ich auch wieder was gelernt!
 
Zurück
Oben