Das erhöht bei großen Daten-Mengen die Selektivität des Indizes auf der Tabelle, sofern mehrere Beziehungen des gleichen Typs zu den gleichen Objekten vorhanden sind. Es handelt sich also um eine Optimierungs-Maßnahme, die IMHO nicht schadet. Denn: eine INT-Spalte belegt nicht so viel Speicherplatz.Was mich auch irritiert ist, dass die Relationstabellen einen Primärschlüssel benötigen. Wofür genau wird der benötigt?
Das gibt es natürlich, denn nur so ist es möglich, die erzeugten Abfragen zu Performance-Optimierungs-Zwecken auch analysieren oder zum Debuggen der Anwendung nutzen zu können. Hierzu muss beim Erzeugen des GORM über die Factory der 5.te Parameter auf true gesetzt werden. Dieser bewirkt, dass alle Abfragen in eine Log-Datei geschrieben werden. Eine direkte Ausgabe macht keinen Sinn, denn sonst produzierst du bei Session-basierten Applikationen ständig "Cannot send session limiter"-Fehler. Die Doku zu diesem Parameter findest du im Kapitel Erzeugen einer Instanz des GORM.Desweiteren wäre eine Mehode sich den Query zu Debuggingszwecken ausgeben zu lassen sinvoll.
Alternativ kann ich natürlich noch eine Option in das Setup- und Update-Tool einbauen, mit dem der Datentyp für Index- und ID-Spalten definiert werden kann - parallel zu Storage-Engine?
Zitat ausIch baue eine Option ein und melde mich, sobald der Code im SVN verfügbar ist.
Einbauen werde ich das zusammen mit den zusätzlichen Indizes.Der Name des Objekts muss bei der Instanziierung immer mitgegeben werden. Erzeugst du selbst ein Objekt, bist du als Entwickler dafür verantwortlich. Beziehst du Objekte vom GORM, wird das für dich erledigt.$user = new GenericDomainObject('User');
echo $user->getObjectName();
$user = new GenericDomainObject('User');
echo $user->get('ObjectName');
,Also in der Dokumenation unter Manuelles SetupAlso erstmal sind die PKs vom Typ INT und nicht TINYINT.
Code: Alles auswählen
`ApplicationID` tinyint(5) NOT NULL auto_increment, Code: Alles auswählen
`GroupID` tinyint(5) NOT NULL auto_increment, Code: Alles auswählen
`UserID` tinyint(5) NOT NULL auto_increment, Das les ich nun zum ersten mal.. Im Manual hab ich dazu auch nichts finden können. Kannst du da etwas näher drauf eingehen? Meinem Verständnis nach kann immer nur 1 Index benutzt werden.Das erhöht bei großen Daten-Mengen die Selektivität des Indizes auf der Tabelle, sofern mehrere Beziehungen des gleichen Typs zu den gleichen Objekten vorhanden sind. Es handelt sich also um eine Optimierungs-Maßnahme, die IMHO nicht schadet. Denn: eine INT-Spalte belegt nicht so viel Speicherplatz.
Korrekt, dort stehen in den Beispiel-Statements noch "TINYINT". Hierzu habe ich jedoch im SVN (ab Revision ) eine Möglichkeit hinzugefügt, dies beim Setup/Update ändern zu können. Beispiel:Also in der Dokumenation unter Manuelles Setup
Code: Alles auswählen
$setup = new GenericORMapperSetup();
$setup->setIndexColumnDataType('BIGINT(100) UNSIGNED');Mir hat das mal ein Oracle-DBA erklärt und ich habe das deshalb so umgesetzt. Im Rahmen des neuen Features Zusätzliche Indizes für Setup-/Update-Tool GORM werde ich mir das Thema nochmal genauer ansehen und einige Performance-Tests für MySQL durchführen.Das les ich nun zum ersten mal.. Im Manual hab ich dazu auch nichts finden können. Kannst du da etwas näher drauf eingehen? Meinem Verständnis nach kann immer nur 1 Index benutzt werden.
Ja, wird er.Wird der {AttributTyp} nur für das automatische Setup der Datenbank benötigt?
Wenn ja, kann ich diesen nicht auch weglassen?
Warum ist beim automatischen Setup keine Konfiguration möglich? Du kannst jeden beliebigen Daten-Typen nutzen. Sofern du diesen ändern musst, kannst du das Update-Tool nutzen. So bleibt die config die zentrale Stelle der Änderung.Da beim automatischen Setup ja keine weiteren Konfigurationen möglich sind, muss ich ja sowieso noch mal Hand anlegen. Wenn ich dann im nachinein den Typ ändere, würde ich dies an zwei Stellen erledigen müssen.