Liebe Mitdenker, liebe Wissende, liebe Neugierige, > n'Abend, > > > > > ~~~ text > > > > clientno type data > > > > -------------------------------- > > > > 70678 Fax 0531/12345-7 > > > > 70678 Tel 0531/12345-0 > > > > 70678 Mail hans@dampf.lan > > > > 70678 Mob 0171/555333555 > > > > ~~~ > > > > > > Könntest Du das Bitte perzisieren, stehe da momentan auf dem Schlauch!? > > > > Statt dass Du dir einen Krampf in der SQL-Schicht codest mit dem vorhandenen (schlechten) Datenmodell und dann voraussichtlich auch in der API noch so verknotet weitermachen musst, könntest Du dein Datenmodell überdenken, und die Eigenschaften (Tel, Fax, Mobile, Mail, ...) aus der Waagerechten (dem Datensatz) herausnehmen und in die Senkrechte (eine eigene Tabelle) verfrachten. > > für diese Anregung hast du von mir schon ein Plus bekommen, zumal dein Beispiel sehr schön zeigt, dass man dann mühelos noch weitere Kontaktmöglichkeiten einbringen kann (hier die Mailadresse). > > Allerdings würde ich dann dringend raten, die Telefonnummern auch normalisiert zu speichern. Dein Beispielauszug enthält noch verschiedene Trennzeichen. Die würde ich dann komplett rauslöschen. > Da Speicherplatz nicht mehr sooo teuer ist, baue ich in solchen Fällen immer zwei Datenspalten auf. Eine mit Formatierung (Slashes, Dashes, Umlaute, Nicht-ASCII-Zeichen, Trallala) und eine normalisierte. Die normalisierte wird immer automatisch durch einen Trigger und eine Benutzerfunktion beschrieben, wenn sich in der formatierten etwas ändert. Die normalisierte ist gegen direktes Beschreiben geschützt. Spirituelle Grüße Euer Robert -- Möge der Forumsgeist ewig leben!

Liebe Mitdenker, liebe Wissende, liebe Neugierige, > n'Abend, > > > > > ~~~ text > > > > clientno type data > > > > -------------------------------- > > > > 70678 Fax 0531/12345-7 > > > > 70678 Tel 0531/12345-0 > > > > 70678 Mail hans@dampf.lan > > > > 70678 Mob 0171/555333555 > > > > ~~~ > > > > > > Könntest Du das Bitte perzisieren, stehe da momentan auf dem Schlauch!? > > > > Statt dass Du dir einen Krampf in der SQL-Schicht codest mit dem vorhandenen (schlechten) Datenmodell und dann voraussichtlich auch in der API noch so verknotet weitermachen musst, könntest Du dein Datenmodell überdenken, und die Eigenschaften (Tel, Fax, Mobile, Mail, ...) aus der Waagerechten (dem Datensatz) herausnehmen und in die Senkrechte (eine eigene Tabelle) verfrachten. > > für diese Anregung hast du von mir schon ein Plus bekommen, zumal dein Beispiel sehr schön zeigt, dass man dann mühelos noch weitere Kontaktmöglichkeiten einbringen kann (hier die Mailadresse). > > Allerdings würde ich dann dringend raten, die Telefonnummern auch normalisiert zu speichern. Dein Beispielauszug enthält noch verschiedene Trennzeichen. Die würde ich dann komplett rauslöschen. > Da Speicherplatz nicht mehr sooo teuer ist, baue ich in solchen Fällen immer zwei Datenspalten auf. Eine mit Formatierung (Slashes, Dashes, Trallala) und eine normalisierte. Die normalisierte wird immer automatisch durch einen Trigger und eine Benutzerfunktion beschrieben, wenn sich in der formatierten etwas ändert. Die normalisierte ist gegen direktes Beschreiben geschützt. Spirituelle Grüße Euer Robert -- Möge der Forumsgeist ewig leben!