Anzahl möglicher Tabellen in einer Postgre 8.0 Datenbank

[sono]

Morgen.

Ich suche gerade die technischen Daten für eine Postgres 8 Datenbank. Für mich wäre es nicht ganz unwichtig zu wissen wieviele Tabellen ich in eine Datenbank bekomme.

Leider hab ich nur Angaben über die physische Größe von Datenbanken und Tabellen gefunden nur das was ich wirklich wissen wollte finde ich in dem Datenoverkill aus Google denn ich bekomme leider nicht.

Im Faq hab ich leider auch nichts gefunden.

Ich hab mal was von 1024 Tabellen gelesen ,weiß aber nicht mehr ob das wirklich PG war.

Nur 1024 wären etwas wenig für meine Zwecke , da müsste ich etwas umplanen, wenn also jemand was weiß , ich wäre über jede Info Dankbar.

 

[lordlamer]

hi!

1. möglichkeit: ne schleife schreiben die nen create table ausführt

2. postgresql hat nur wenig einschränkungen. die größte einschränkung stellt immer die hardware da bei postgresql. ich behaupte mal du kannst also schier unendlich viele tabellen erstellen.

die frage die sich mir auf jedenfall stellt ist: wofür brauchst du soviele tabellen?

mfg frank

 

[sono]

Für ein DatenManagementSystem mit theoretisch mehreren Hundert Kunden, wobei jeder Kunde zwecks Datensicherung , Datensicherheit und Datenschutz sowie eben der Benutzerverwaltung für bestimmte Dienste einen gewissen Anzahl Tabellen benötigt , was wiederum alles in einer Datebank ablaufen muss weil sonst die Joins und Subquerys mit den Publictabellen nicht mehr gehen würden was unfein wäre .

Ich weiß Zumindest dass ich "Nur" 1600 Spalten in einer Tabelle haben kann (PG 8.1 ) , aber das ich mehr als Ausreichen , da eigentlich nur die Anzahl der Tabellen ziemlich krass ist, die der Spalten aber relativ gering ist.

Und da es sein kann das in das System auf einen Schlag 2000 Kunden kommen könnte es passieren dass ich plötzlich ca 40.000 Tabellen habe + - 10 % da ich pro Kunde eine Variable Anzahl von Tabellen habe.

Hm Krasse Zahl , aber wie gesagt durch bestimmte Sicherheitsbestimmungen , und Datenschutzrechtliche Dinge müssen die Tabellen der Kunden dvoneinander getrennt sein , sonst könnte Kunde a unter ganz doofen Umständen vielleicht die Daten bei Kunde XYZ auslesen was etwas uncool wäre .

Hm ich schau nochmal weiter , auf die Try and Error Methode will ich mich erst mal nicht verlassen.

Aber ich Klopf auf den Testrechner mal schnell 50.000 Tabellen , und wenn er dann noch lebt , dann weiß ich das es geht ;

NACHTRAG:

Hatte gerade 4000 Tabellen in einer Datenbank.
Im Moment läuft das Script für die 50000 Tabellen. Öhm es läuft noch , aber sieht so aus als ob das gehen sollte.

OK Endergebnis , bei ca 25.000 Tabellen war Postgres fast nur noch damit beschäftigt sich selbst zu verwalten , allerdings war der Testrechner mein Latop und der nicht unbedingt ein High End Server.

Ich teste dass nochmal auf einer etwas netteren Maschine und dann schaun wir mal was auskommt.

Gruß Sono

 

[lordlamer]

hi

aber das klingt alles etwas unlogisch wenn du eigentlich immer wieder die daten in der selben struktur speicherst. aber das in neuen tabellen.

ich habe deinen einwand wegen datensicherheit etc ja verstanden. aber verstehe das prinzip ja dahinter trotzdem noch net so ganz was das bringen soll. wie soll der kunde den seine daten pflegen? selber per sql? wäre toll wenn du dazu mal was sagen könntest.

mfg frank

 

[sono]

Öhm eigentlich wollte ich nur wissen wieviele Tabellen ich in eine Datenbank bekomme und nicht die Architektur meines System disskutieren.

Aber du hast es nicht anderst gewollt ,

Also ich habe eine System das Im Web Daten für Kunden speichert .

Der Zugriff , das Manipulieren oder Erstellen von Daten erfolgt über ein Webinterface des Benutzers oder eine gesicherte XML Schnittstelle also nie direkt . Jeder Benutzer hat Zugriff auf seine eigenen Daten und auf einige öffentliche Tabellen ( ab 10 Tabellen bis oben offen ) . Um sicherzustellen dass der User selbst bei einem Programmierfehler oder sonstigen Probleme im System nur an seine eigenen Daten kommt ,( und nicht plötzlich die Daten von einem anderen User in seinem System angezeigt bekommt ) hat jeder Benutzer einen eigenen Benutzer in der Datenbank , der eben nur auf seine Privaten und auf die öffentliche Daten kommt. Nebenbei kann jeder User so einfach seine eigenen Tabellen importieren und exportieren ohne die Daten von anderen Usern zu haben usw.

Das es bei einigen Aktionen wie gesagt Joins und Subquerys zwischen Öffentlichen und Privaten Daten gibt muss alles in eine Datenbank , oder ich muss die öffentlichen Tabellen in mehrenren Datenbanken parallel einpflegen und ständig synchonisieren wass ich so lange ich alles auf einem Server belassen kann vermeinden möchte.


Sprich einmal wird eben die Benutzerverwaltung der Datenbank mitbenutzt um die Sicherheit und die Privatsphäre zu verstärken , und dann wird eben die allgemeine Verwaltung der Daten dadurch so simpel wie möglich gehalten.

Sollte dir eine Lücke im Konzept auffallen , dann bin ich für jeden Kritikpunkt dankbar. Mann kann ja schlieslich nicht alles berücksichtigen und 2 Menschen haben mehr Erfahrung als einer .

aber das klingt alles etwas unlogisch wenn du eigentlich immer wieder die daten in der selben struktur speicherst. aber das in neuen tabellen.

Ich denke mal das Klar geworden ist dass es zu einem großen Teil um die Datenbankbenutzerverwaltung geht , mit der man recht komfortabel die Rechte in den Tabellen verwalten kann .

Gruß Sono