Tabellen mit mehrsprachigen Eintraegen

Hallo Gott! Hallo Welt!

Ich wollte mal fragen, wie Ihr Eure Tabellen erstellt, wenn sie
mehrsprachige Einträge enthalten.

Mir sind zwei Methoden eingefallen:

1.) Jede Zeile mehrmals:

CREATE TABLE subject (
id INT(10) UNSIGNED NOT NULL,
name VARCHAR(40),
`language id` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (id,`language id`)
);

Einträge sähen dann wie folgt aus:

(1,'Hallo, dies ist das erste Posting',1)
(1,'Hello, this is the first posting', 2)
(2,'Eins, zwei, drei', 1)
(2,'One, two, three', 2)

Vorteile:

- Einfach um beliebig viele Sprachen erweiterbar
- Man hat bei einem JOIN automatisch immer die richtige Spalte in der
richtigen Sprache. Also zum Beispiel:
SELECT
subject.name
FROM
subject
LEFT JOIN
...
ON
... = subject.id
WHERE
subject.`language id' = 2

Nachteil:
- Man muß beim INSERT die IDs manuell vergeben und kann
AUTO_INCREMENT nicht nutzen

2.) entsprechende Spalten mehrmals in der Tabelle:

CREATE TABLE subject (
id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`name (de)` VARCHAR(40),
`name (en)` VARCHAR(40),
PRIMARY KEY (id)
);

Einträge sähen dann so aus:

(1,'Hallo, dies ist das erste Posting','Hello, this is the first posting')
(2,'Eins, zwei, drei','One, two, three')

Vorteil:
- IDs werden automatisch per AUTO_INCREMENT vergeben

Nachteile:
- Bei vielen Sprachen wir die Tabelle sehr "breit" und unübersichtlich
- JOINs und SELECTs sind nicht mehr so schön, weil man beim erstellen
des JOIN- und SELECT-Strings auch immer die Spalte welche man SELECTen
will setzen muß:

SELECT
`name (de)`
FROM
subject

ist nicht so schön, wie

SELECT
name
FROM
subject
WHERE
`language id` = ?

Wie habt Ihr dieses Problem gelöst. Bisher habe ich Methode eins
genutzt, bin aber unzufrieden damit. Methode zwei erscheint mir zur Zeit
sympathischer, aber ich frage mich, ob es nicht ein schönere Methode
gibt, die keine der genannten Nachteile hat.

Ciao

Alex

Re: Tabellen mit mehrsprachigen Eintraegen

Alexander Vipach wrote:
> Hallo Gott! Hallo Welt!

Kannst mich Frank nennen :-P

> Ich wollte mal fragen, wie Ihr Eure Tabellen erstellt, wenn sie
> mehrsprachige Einträge enthalten.
>
> Mir sind zwei Methoden eingefallen:
>
> 1.) Jede Zeile mehrmals:

Gute Idee, ich hab das mal etwas angepasst (es gibt ISO Standards für
Sprachenkennzeichnung)

CREATE TABLE subject (
textid varchar(30),
langid varchar(5),
name VARCHAR(255),
PRIMARY KEY (textid,langid)
);

Einträge sähen dann wie folgt aus:

('hallo','Hallo, dies ist das erste Posting','de_DE')
('hallo','Hello, this is the first posting', 'en_GB')
('blabla','Eins, zwei, drei', 'de_DE')
('blabla','One, two, three', 'en_GB')

Dazu solltest du in einer extra Tabelle noch Charsets und andere
sprachspezifische Attribute zu jeder Sprache hinterlegen.

gruß, Frank

Re: Tabellen mit mehrsprachigen Eintraegen

Frank Schenk wrote:

> langid varchar(5)

Wäre es hier nicht besser ein char(5) zu nehmen. Da die Länge der Kennung
immer gleich lang bleibt und daher varchar hier 6 Bytes pro Eintrag belegt
und char nur 5 Bytes. Bei 10.000 Einträge == 9,766 MB eingespart.

Das sollte hier keine Kritik sein, sondern nur ein Hinweise/Anstoss auf die
richtige Verwendung von Datentypen. :-)


MfG,
Thomas

Re: Tabellen mit mehrsprachigen Eintraegen

Thomas Enzinger wrote:
> Frank Schenk wrote:
>
>> langid varchar(5)
>
> Wäre es hier nicht besser ein char(5) zu nehmen. Da die Länge der Kennung
> immer gleich lang bleibt und daher varchar hier 6 Bytes pro Eintrag belegt
> und char nur 5 Bytes. Bei 10.000 Einträge == 9,766 MB eingespart.

Rechne nochmal nach und überlege, ob sich das überhaupt noch lohnt, zumal...

> Das sollte hier keine Kritik sein, sondern nur ein Hinweise/Anstoss auf die
> richtige Verwendung von Datentypen. :-)

.... MySQL ab CHAR(>3) ohnehin in VARCHAR(>3) umwandelt [1], wenn noch
andere Spalten mit variabler Länge (wie in diesem Fall) vorhanden sind.

Grüße
Kai

[1] http://dev.mysql.com/doc/refman/5.0/en/silent-column-changes .html

--
This signature is left as an exercise for the reader.

Re: Tabellen mit mehrsprachigen Eintraegen

Thomas Enzinger wrote:
>
>> langid varchar(5)
>
> Wäre es hier nicht besser ein char(5) zu nehmen. Da die Länge der Kennung
> immer gleich lang bleibt und daher varchar hier 6 Bytes pro Eintrag belegt
> und char nur 5 Bytes. Bei 10.000 Einträge == 9,766 MB eingespart.

Es sind 10,24 gesparte MB, aber Plattenplatz ist billig. Viel mehr würde
mich da der nötige Overhead stören, der durch die Berechnungen der
Datensatzpositionen entsteht. Aber wie bereits von Kai erwähnt, würde
MySQL diese Spalte ja eh umwandeln.

> Das sollte hier keine Kritik sein, sondern nur ein Hinweise/Anstoss auf die
> richtige Verwendung von Datentypen. :-)

Wenn es keine Kritik ist, was ist es dann? Kritik immer was Gutes,
solange sie konstruktiv ist. Das verstehen die Leute nur nie...


Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal

Re: Tabellen mit mehrsprachigen Eintraegen

Dominik Echterbruch wrote:
> Thomas Enzinger wrote:
>>
>>> langid varchar(5)
>>
>> Wäre es hier nicht besser ein char(5) zu nehmen. Da die Länge der
>> Kennung
>> immer gleich lang bleibt und daher varchar hier 6 Bytes pro Eintrag
>> belegt
>> und char nur 5 Bytes. Bei 10.000 Einträge == 9,766 MB eingespart.
>
> Es sind 10,24 gesparte MB, aber Plattenplatz ist billig. Viel mehr würde
> mich da der nötige Overhead stören, der durch die Berechnungen der
> Datensatzpositionen entsteht.

Ich bleibe dabei, dass es allenfalls Kilobyte sind. Für Mega fehlen da
bei der Menge der Datensätze noch zwei Nullen. Zum anderen sollte man
solche Vergleiche immer in den Kontext der durchschnittlichen
Datensatzlänge einbetten. Da kommen dann ganz schnell ganz kleine
Prozentwerte bei raus. 10KB Ersparnis bei 450KB Daten merkt man nicht
wirklich ( durchschnittlich: textid 10 Zeichen, langid 5 Zeichen, name
30 Zeichen = 45 Zeichen *10.000 Datensätze).

[snip]
>> Das sollte hier keine Kritik sein, sondern nur ein Hinweise/Anstoss
>> auf die
>> richtige Verwendung von Datentypen. :-)
>
> Wenn es keine Kritik ist, was ist es dann? Kritik immer was Gutes,
> solange sie konstruktiv ist. Das verstehen die Leute nur nie...

*seufz* Da hast du recht.

Grüße
Kai

--
This signature is left as an exercise for the reader.

Re: Tabellen mit mehrsprachigen Eintraegen

Kai Ruhnau wrote:
>>>> langid varchar(5)
>>>
>>> Wäre es hier nicht besser ein char(5) zu nehmen. Da die Länge der
>>> Kennung
>>> immer gleich lang bleibt und daher varchar hier 6 Bytes pro Eintrag
>>> belegt
>>> und char nur 5 Bytes. Bei 10.000 Einträge == 9,766 MB eingespart.
>>
>> Es sind 10,24 gesparte MB, aber Plattenplatz ist billig. Viel mehr
>> würde mich da der nötige Overhead stören, der durch die Berechnungen
>> der Datensatzpositionen entsteht.
>
> Ich bleibe dabei, dass es allenfalls Kilobyte sind. Für Mega fehlen da
> bei der Menge der Datensätze noch zwei Nullen.

Ups, ja, stimmt. Ich hab mich so sehr daran fest gebissen, daß der Wert
falsch ist, daß ich bei der Korrektur versehentlich die Zahl geändert
hab, statt der Einheit ;)
Naja, ist eh Zeit für's Bett...


Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal

Re: Tabellen mit mehrsprachigen Eintraegen

Alexander Vipach wrote:
> Hallo Gott! Hallo Welt!
>
> Ich wollte mal fragen, wie Ihr Eure Tabellen erstellt, wenn sie
> mehrsprachige Einträge enthalten.
>
> Mir sind zwei Methoden eingefallen:
>
> 1.) Jede Zeile mehrmals:
>
> CREATE TABLE subject (
> id INT(10) UNSIGNED NOT NULL,
> name VARCHAR(40),
> `language id` INT(10) UNSIGNED NOT NULL,
> PRIMARY KEY (id,`language id`)
> );
[snip]
> 2.) entsprechende Spalten mehrmals in der Tabelle:
>
> CREATE TABLE subject (
> id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
> `name (de)` VARCHAR(40),
> `name (en)` VARCHAR(40),
> PRIMARY KEY (id)
> );

Mir ist eben noch eine weiter Möglichkeit eingefallen, die der
Normalisierung besser entsprechen würde. Man nehme drei Tabellen:
sprache (id, name)
subject (id, lustige_weitere_attribute)
subject_sprache (id, spracheid, subjectid, name)

Vorteil: die IDs für den Subject können automatisch generiert werden,
ohne daß die Tabellenstruktur jemals wieder angepasst werden muß.
Nachteil: aufwändigere INSERTs (einer für den Subject, und je einer für
jede Übersetzung).

> Wie habt Ihr dieses Problem gelöst. Bisher habe ich Methode eins
> genutzt, bin aber unzufrieden damit. Methode zwei erscheint mir zur Zeit
> sympathischer, aber ich frage mich, ob es nicht ein schönere Methode
> gibt, die keine der genannten Nachteile hat.

Gibt es, aber dafür hat sie andere Nachteile :)


Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal

Re: Tabellen mit mehrsprachigen Eintraegen

Hi

> Ich wollte mal fragen, wie Ihr Eure Tabellen erstellt, wenn sie
> mehrsprachige Einträge enthalten.
> =

> Mir sind zwei Methoden eingefallen:
> =

> 1.) Jede Zeile mehrmals:
> =

> CREATE TABLE subject (

[...]

> sympathischer, aber ich frage mich, ob es nicht ein schönere Methode
> gibt, die keine der genannten Nachteile hat.

Auch wenn du es eventuell nicht für möglich hälts, verwende ich
in einem Projekt beide Konstrukte.

1) Für jede Sprache eine Spalte für Beschriftungen, Texte
2) Bei DB einträgen führe ich die Sprache in einer Spalte mit.

zu 1:
Meines Erachtens leichter zu handhaben, da gleichzeitig
2 alternative Sprachen geladen werden, falls mal ein
Wort noch nicht übersetzt wurde. =


zu 2:
Besser für Suchanfragen und auch Platzsparender, da nicht
jeder Kunde für jede Sprache einen Eintrag schreibt.

gruß n.Olivier
-- =

Nachbagauer Olivier, Technologiezentrum, D-83395 Freilassing =

www.nOlivier.com - www.Reedb.com - www.Immofinder.de

Re: Tabellen mit mehrsprachigen Eintraegen

Alexander Vipach wrote:
> Hallo Gott! Hallo Welt!

#include "standardwitz.txt"

> Ich wollte mal fragen, wie Ihr Eure Tabellen erstellt, wenn sie
> mehrsprachige Einträge enthalten.

> 1.) Jede Zeile mehrmals:
>
> CREATE TABLE subject (
> id INT(10) UNSIGNED NOT NULL,
> name VARCHAR(40),
> `language id` INT(10) UNSIGNED NOT NULL,
> PRIMARY KEY (id,`language id`)
> );

Warum eigentlich `name`? Und Leerzeichen in Attributnamen solltest du
prinzipiell vermeiden. Ansonsten wäre das die normalisierte Lösung,

> Nachteil:
> - Man muß beim INSERT die IDs manuell vergeben und kann
> AUTO_INCREMENT nicht nutzen

Stimmt nicht. Die folgende Tabelle tut genau das, was du willst.

CREATE TABLE subject (
id INT UNSIGNED AUTO_INCREMENT,
lang_id INT UNSIGNED,
string VARCHAR(40),
PRIMARY KEY (lang_id, id)
)

http://dev.mysql.com/doc/refman/5.0/en/example-auto-incremen t.html


> 2.) entsprechende Spalten mehrmals in der Tabelle:

Das ist nicht normalisiert. Die Nachteile liegen auf der Hand:

- eine neue Sprache braucht eine neue Spalte -> Dein Schema ist nicht
mehr konstant, sondern datenabhängig. Außerdem ist ALTER TABLE in
MySQL ziemlich teuer.

- Daten (der Sprach-Identifier) stehen im Spaltennamen. Ganz böse.
Wie schreibst du einen JOIN um User Alexander das passende Subjekt
zu zeigen, wenn die Sprachpräferenz von Alexander in der `user`
Tabelle in Spalte `preferred_language` steht?


XL

Re: Tabellen mit mehrsprachigen Eintraegen

Thomas Enzinger wrote:
> Frank Schenk wrote:
>
>
>> langid varchar(5)
>
>
> Wäre es hier nicht besser ein char(5) zu nehmen. Da die Länge der Kennung
> immer gleich lang bleibt und daher varchar hier 6 Bytes pro Eintrag belegt
> und char nur 5 Bytes. Bei 10.000 Einträge == 9,766 MB eingespart.
>
> Das sollte hier keine Kritik sein, sondern nur ein Hinweise/Anstoss auf die
> richtige Verwendung von Datentypen. :-)

man mysql :-P


Frank

Re: Tabellen mit mehrsprachigen Eintraegen

Hallo Axel!

>> Hallo Gott! Hallo Welt!
>
> #include "standardwitz.txt"

Kein Problem, gern geschehen! :-)

Korrekt heißt es aber glaube ich:

use witz::standard;

:-)

> Stimmt nicht. Die folgende Tabelle tut genau das, was du willst.
>
> CREATE TABLE subject (
> id INT UNSIGNED AUTO_INCREMENT,
> lang_id INT UNSIGNED,
> string VARCHAR(40),
> PRIMARY KEY (lang_id, id)
> )

Cool, vielen Dank! Ich wußte nicht das es beim Primary Key einen
Unterschied macht, in welcher Reihenfolge man den schreibt. Wenn man die
language id als erstes schreibt funktioniert es in der Tat wunderbar!

>> 2.) entsprechende Spalten mehrmals in der Tabelle:
>
> Das ist nicht normalisiert. Die Nachteile liegen auf der Hand:

Jupp, fand die zweite Lösung ja auch nicht gut. Das habe ich doch
geschrieben, oder?

Ciao

Alex

Re: Tabellen mit mehrsprachigen Eintraegen

Alexander Vipach wrote:

>> CREATE TABLE subject (
>> id INT UNSIGNED AUTO_INCREMENT,
>> lang_id INT UNSIGNED,
>> string VARCHAR(40),
>> PRIMARY KEY (lang_id, id)
>> )
>
> Cool, vielen Dank! Ich wußte nicht das es beim Primary Key einen
> Unterschied macht, in welcher Reihenfolge man den schreibt.

Macht es nicht.

> Wenn man die
> language id als erstes schreibt funktioniert es in der Tat wunderbar!

Das gibt das Gleiche wie ein PK(id) und ist nicht das, was du wolltest.

Eine eindeutige id für mehrere lang_ids (1-1,1-2,1-3,2-1,2-2,3-1,3-2) in
einer Tabelle geht nicht mit Autoinc, aber mit Dominiks Vorschlag.

Dieter

Re: Tabellen mit mehrsprachigen Eintraegen

Dieter Noeth wrote:

> Alexander Vipach wrote:
>
>>> CREATE TABLE subject (
>>> id INT UNSIGNED AUTO_INCREMENT,
>>> lang_id INT UNSIGNED,
>>> string VARCHAR(40),
>>> PRIMARY KEY (lang_id, id)
>>> )
>>
>> Cool, vielen Dank! Ich wußte nicht das es beim Primary Key einen
>> Unterschied macht, in welcher Reihenfolge man den schreibt.
>
> Macht es nicht.

Doch, siehe Handbuch.

Wenn die Auto_Increment-Spalte in einem zweiteiligen PK die 2. ist, dann
numeriert sie innerhalb des ersten Teiles jeweils neu durch.

Hm, unverständlich. Beispiel: s.o.
Ich füge nun drei Einträge mit lang_id=1 ein, die werden brav
durchnumeriert: 1,2,3. Füge ich vier weitere mit lang_id=2 ein, werden
diese separat und neu numeriert: 1,2,3,4 usw.


Thomas

Re: Tabellen mit mehrsprachigen Eintraegen

Dieter Noeth wrote:
>
>>> CREATE TABLE subject (
>>> id INT UNSIGNED AUTO_INCREMENT,
>>> lang_id INT UNSIGNED,
>>> string VARCHAR(40),
>>> PRIMARY KEY (lang_id, id)
>>> )
>>
>> Cool, vielen Dank! Ich wußte nicht das es beim Primary Key einen
>> Unterschied macht, in welcher Reihenfolge man den schreibt.
>
> Macht es nicht.

Macht es doch. Aus welchem Grund auch immer. Es will mir nicht wirklich
einleuchten, warum das eingebaut wurde, aber praktisch ist es allemal.

CREATE TABLE `subject` (
`id` int(10) unsigned NOT NULL auto_increment,
`langid` int(10) unsigned NOT NULL,
`string` char(10) default NULL,
PRIMARY KEY (`langid`,`id`)
)

INSERT INTO subject VALUES (NULL, 1, 'deutsch');
INSERT INTO subject VALUES (NULL, 2, 'english');
INSERT INTO subject VALUES (NULL, 1, 'hallo');
INSERT INTO subject VALUES (NULL, 2, 'hello');

SELECT * FROM subject;
+----+--------+---------+
| id | langid | name |
+----+--------+---------+
| 1 | 1 | deutsch |
| 1 | 2 | english |
| 2 | 1 | hallo |
| 2 | 2 | hello |
+----+--------+---------+


Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal

Re: Tabellen mit mehrsprachigen Eintraegen

Dominik Echterbruch wrote:
> Dieter Noeth wrote:
>>
>>>> CREATE TABLE subject (
>>>> id INT UNSIGNED AUTO_INCREMENT,
>>>> lang_id INT UNSIGNED,
>>>> string VARCHAR(40),
>>>> PRIMARY KEY (lang_id, id)
>>>> )
>>>
>>> Cool, vielen Dank! Ich wußte nicht das es beim Primary Key einen
>>> Unterschied macht, in welcher Reihenfolge man den schreibt.
>>
>> Macht es nicht.
>
> Macht es doch. Aus welchem Grund auch immer. Es will mir nicht wirklich
> einleuchten, warum das eingebaut wurde, aber praktisch ist es allemal.

AFAIK wurde das auf Wunsch eines Kunden eingebaut :-)

Ob es *wirklich* das ist, was Alexander braucht, dessen bin ich mir
mittlerweile nicht mehr *so* sicher. Vom Design-Standpunkt will man
eine eindeutige ID für Subjekte und eine 1:n Relation zu Übersetzungen.
In obige Tabelle kann man z.B. erst eine Menge deutsche Subjekte
einfügen, die auch hypsch durchnumeriert werden. Wenn dann das erste
englische kommt, bekommt es eine ID, die bereits für ein deutsches
Subjekt vergeben wurde - obwohl es mit diesem nichts zu tun haben muß.

Zwei Tabellen wären vermutlich eher angemessen, vorausgesetzt ein
Subjekt hat außer der ID noch Attribute die für alle Übersetzungen
gleich sind. Sonst reicht eine Sequenz für die ID. Sequenzen kann
man emulieren: http://forge.mysql.com/snippets/view.php?id=7


XL

Re: Tabellen mit mehrsprachigen Eintraegen

Thomas Rachel wrote:

> Wenn die Auto_Increment-Spalte in einem zweiteiligen PK die 2. ist, dann
> numeriert sie innerhalb des ersten Teiles jeweils neu durch.
>
> Hm, unverständlich. Beispiel: s.o.
> Ich füge nun drei Einträge mit lang_id=1 ein, die werden brav
> durchnumeriert: 1,2,3. Füge ich vier weitere mit lang_id=2 ein, werden
> diese separat und neu numeriert: 1,2,3,4 usw.

Interesant, gar nicht mal so dumm...
Sowas mache ich normalerweise beim Insert/Select über die SQL:1999
OLAP-Funktionen (ROW_NUMBER, nicht in mysql).

Passt aber vermutlich immer noch nicht für den OP:
Dabei müssten jetzt immer alle lang_ids pro id eingefügt werden (und
auch in der richtigen Reihenfolge), sobald einmal eine Sprache fehlt,
stimmt die Nummerierung nicht mehr :-(

Dieter

Re: Tabellen mit mehrsprachigen Eintraegen

Hallo Dieter!

> Passt aber vermutlich immer noch nicht für den OP:
> Dabei müssten jetzt immer alle lang_ids pro id eingefügt werden (und
> auch in der richtigen Reihenfolge), sobald einmal eine Sprache fehlt,
> stimmt die Nummerierung nicht mehr :-(

Jupp, das ist mir auch schon aufgefallen. Da ich die Tabelle zur Zeit
aber immer mit einem Eintrag in allen Sprachen fülle, funktioniert diese
Lösung wunderbar. Würde man die Einträge und Sprachen bunt mischne,
würde diese Lösung natürlich leider nicht mehr funktionieren.

Ciao

Alex

Re: Tabellen mit mehrsprachigen Eintraegen

Hi

Alexander Vipach schrieb:
> =

> Hallo Dieter!
> =

> > Passt aber vermutlich immer noch nicht für den OP:
> > Dabei müssten jetzt immer alle lang_ids pro id eingefügt we=
rden (und
> > auch in der richtigen Reihenfolge), sobald einmal eine Sprache fehlt,=

> > stimmt die Nummerierung nicht mehr :-(
> =

> Jupp, das ist mir auch schon aufgefallen. Da ich die Tabelle zur Zeit
> aber immer mit einem Eintrag in allen Sprachen fülle, funktioniert=
diese
> Lösung wunderbar. Würde man die Einträge und Sprachen bu=
nt mischne,
> würde diese Lösung natürlich leider nicht mehr funktioni=
eren.

Bei diesem Konstrukt (und auch allgemein) sollte die ID nebensache
sein, da diese 'nur' für die Eindeutigkeit eines DS stehen soll.

Für das richtige laden des richtigen DS für einen eintrag in einer
beliebigen Sprache kommst du nicht umhin, manuelle ID's zu verwenden.

Damit dies nicht ganz unübersichtlich wird, habe ich mir 2 ID's =

angewöhnt. 1x class (definiert das Formular) + 1x wert (definiert
das feld, welches befüllt wird)

Somit sieht ein Eintrag z.B. so aus

ID class field wert lang
3 home benutzer User en
4 home text1 Hallo en

und bei der Spaltenweisen speicherung

ID class field en de
3 home benutzer User Benutzer
4 home text1 Hello Hallo

gruß n.Olivier
-- =

Nachbagauer Olivier, Technologiezentrum, D-83395 Freilassing =

www.nOlivier.com - www.Reedb.com - www.Immofinder.de