Hallo zusammen,
ich habe ca. 45.000 Adressen im cRM. (Teilweise uralt/tot, aber lassen wir das.)
Es handelt sich um Privatkunden, gewerbliche Kunden und Lieferanten (ist so gewollt). Nun gibt es ein paar Angaben, die nur bei bestimmten Adress-Arten eine Rolle spielen, z.B. bei Lieferanten die Angabe, was sie liefern.
Diese Informationen sind in einer Handvoll Code-Feldern in der Adress-Ansicht gespeichert. Die Daten liegen also direkt in der SQL-Tabelle für die Adress-Ansicht. Das bedeutet, dass bei gefühlten 98% aller Adressen nur leere Spalten in der SQL-Tabelle gespeichert sind.
Nun frage ich mich, ob es nicht sinnvoll wäre, diese Zusatz-Informationen in einer separaten Tabelle/Ansicht auszulagern und eine 1:1-Verknüpfung mit der Adress-Ansicht zu erstellen. So würde ich nicht bei so vielen Datensätzen unnütze Felder mitschleppen. Mal abgesehen davon, dass dies ein paar Bytes sparen würde:
Normalerweise würde ich ja den Primärschlüssel der Adress-Ansicht als Fremdschlüssel in der Zusatz-Ansicht speichern. Was wäre, wenn ich zur Verknüpfung den Primärschlüssel der Zusatz-Ansicht in einem neuen Feld der Adress-Ansicht ablege: Würde der cRM dann bei jedem Öffnen der Adress-Ansicht nach dem 1:1-verknüpften Datensatz in der Zusatz-Ansicht suchen, oder ist er intelligent genug, nicht auf die Zusatz-Ansicht zu zu greifen, wenn der Fremdschlüssel NULL ist? Dann würde ich ja tatsächlich mehr Performance rausholen.
Hat jemand sich schonmal damit beschäftigt und kann Erfahrungswerte zur Performance nennen?
MfG,
Nico Minuth
Ein gutes Neues allerseits,
meine Empfehlung: lass es! 
Meine Gründe:
a) die Einsparung bzgl. der Breite ist marginal, dafür handelst du dir aber hinter den Kulissen jede Menge 1:1 Abfragen ein. Der cRM ist zwar so schlau, die Abfrage für den jeweiligen konkreten Datensatz nicht durchzuführen, falls das Fremdschlüsselfeld dort null ist, aber da er die ganzen 1:1 Felder ja direkt auch in die „Struktur“ des Datensatzes der Ansicht mit einblendet (was ich auch extrem praktisch finde), muss er nicht nur den Datensatz der Ansicht abrufen, sondern auch alle damit direkt 1:1 verknüpften Ansichten „zusammensammeln“ (wegen Feld-Anzahl, Feldnamen, Feldtypen etc.), egal ob er dann für den konkreten Datensatz nachher jeweils Daten abruft oder nicht. Das machte er zwar (wohl) nur einmal, aber er muss es halt machen.
b) Filter werden unnötig komplex: relational verknüpfte Datensätze sind bei Filter - Allgemein immer implizit UND verknüpft („JOIN lässt grüßen“). Wenn du aber nun sowas brauchst wie „alle Firmen, die in Hamurg sitzen ODER das Produkt xyz liefern“ (letzteres sei das betreffende Code-Feld), dann musst du plötzlich mit freien SQL Abfragen arbeiten
Ich würde die Code-Felder so kurz wie nötig machen, so dass du etwas Luft für Erweiterungen hast, ohne gleich das Feld wieder verlängern zu müssen, aber eben nicht gleich 160 Zeichen verballerst: evtl. reichen ja auch 30 (pot.) Codeeinträge.
Gruß
Alex
Hallo Alex,
vielen Dank für Deine ausführliche Antwort.
Weder an die Ermittlung der „Struktur“ aller relational verknüpften Ansichten, noch an das Problem bei einer „Oder“-Verbindung von Suchkriterien bei „Filter allgemein“ hatte ich bislang gedacht.
„Filter allgemein“ würde ja noch funktionieren, wenn man die Kriterien im Eingabefeld für eine Ansicht „versammelt“ und dort mit OR verknüpft. Aber versuch das mal einem Kollegen zu erklären, der mit SQL nicht besonders gut klar kommt. 
Dann werde ich die Optimierungen mal darauf beschränken, aus den seit Jahren rumliegenden ca. drei Dutzend logischen Feldern ein paar wenige Codefelder zu machen. (Ist kein Witz, der frühere Support-Partner meines Brötchen-Gebers hat das gemacht. Zu seiner Verteidigung sei gesagt, dass die Erst-Einrichtung noch mit dem cRM 2005 war und die Tabellen-Struktur seit dem sträflich vernachlässigt wurde.)
Die Codefelder bleiben dann eben auch in der Adress-Ansicht; die paar Bytes fressen ja kein Brot…
Gruß,
Nico.
