2 Groove: \r
Дело в том что я физически не смогу сам заполнить справочники, поэтому придется доверить это дело "профессионалам" (девочкам, которые ничего кроме как быстро печатать не умеют) \r
и может получиться такая ситуация, что одновременно в разных БД появятся например: \r
ФИРМА-ПРОИЗВОДИТЕЛЬ Toyota \r
МОДЕЛЬ Mark II \r
\r
ФИРМА-ПРОИЗВОДИТЕЛЬ ТОЙОТА \r
МОДЕЛЬ МАРК 2 \r
\r
Что с ними делать? \r
\r
На самом деле рамки допустимого бардака в справочнике (БД) должен определять заказчик системы в требованиях к этой системе. Если бы вы их указали точно , то можно было бы говорить конкретнее\r
\r
Если "заказчик" вы сам, т.е вы продаете систему, к-рую спроектировали по своим же требованиям, то вы и должны решать насчет дублирующихся по смыслу названий. Тогда вы имеете полное право (кстати, это выглядит абсолютно естественно) предлагая свою систему указать в документации, что, например, ...бла-бла..названия фирм-производителей только на одном языке..дабы не было дублирования...".\r

Если заказчик не вы, то это другое дело и тогда следует выяснить его требования, но даже в этом случае вы можете рассчитывать на некий минимальный общечеловеческий умственный и уровень ответственности тех, кто будет работать со справочником. Потому что абсолютной защиты от дурака не существует. В мире существуют многие тысячи разных электронных справочников и IMHO наврядли хотя бы в 1% из них есть такие интеллектуальные антибардачные механизмы\r
\r
Так что вы в любом случае зря занимаетесь творчеством по поводу интеллектуальных антибардачных механизмов - заказчик просто не оценит, а вы время потратите. Хотя опыт может пригодиться в будущем.\r
Теперь вдобавок к тому, что уже тут высказали, если исходить из неких возможных требований:\r
\r
Вариант 1. \r
Требования:\r
1. Названия фирм-производителей, означающих одну и ту же фирму недопустимы \r
в справочнике.\r
2. Все названия фирм-производителей в справочнике - только на одном языке \r
(например, русском).\r
3. Справочник должен предоставлять пользователю возможность выбора из уже имеющегося\r
списка фирм-производителей прежде, чем он добавит новое название.\r
---\r
Решение:\r
создать интерфейс пользователя и валидатор для вводимых в справочник названий фирм-производителей, чтобы вводимые названия удовлетворяли требованиям 1-3. Такой валидатор на стороне БД/клиента - очень простая вещь\r
\r
Вариант 2. \r
Требования:\r
1. Названия фирм-производителей, означающих одну и ту же фирму недопустимы \r
в справочнике.\r
2. Все названия фирм-производителей в справочнике - только на одном языке \r
(например, русском).\r
3. Справочник должен предоставлять пользователю возможность выбора из уже имеющегося\r
списка фирм-производителей прежде, чем он добавит новое название.\r
4. Справочник должен "отлавливать" похожие названия , означающие\r
одну и ту же фирму-производитель.\r
Критерии похожести названий: .........например, пусть похожими считаются названия типа:\r
"TOYOTA" и "TAYOTA" , "MERCEDES-BENZ" и "MERSEDES-BENS" , "VOLKSWAGEN" и "FOLKSVAGEN"..\r
- т.е у похожих названий отличаются макс.на 1-2 буквы.\r
---\r
Решение: \r
создать интерфейс пользователя и валидатор для вводимых в справочник названий фирм-производителей, чтобы вводимые названия удовлетворяли требованиям 1-4. Такой валидатор на стороне БД/клиента - вещь, простота к-рой зависит от критериев похожести названий. Если взять те критерии, что выше, то валидатор достаточно прост поскольку есть различные библиотеки таких функций. В TSQL есть те же soundex() и difference()\r
\r
Вариант 3. \r
Требования:\r
1. Названия фирм-производителей, означающих одну и ту же фирму допустимы \r
в справочнике: 1 название на английском и 1 название на русском языке.\r
2. Все названия фирм-производителей в справочнике - на русском \r
и английском языках.\r
3. Справочник должен предоставлять пользователю возможность выбора из уже\r
имеющегося списка фирм-производителей прежде, чем он добавит новое название.\r
4. Справочник должен "отлавливать" похожие названия , означающие одну\r
и ту же фирму-производитель, если эти названия на одном языке.\r
Критерии похожести названий: .........например, пусть похожими считаются названия типа:\r
"TOYOTA" и "TAYOTA" , "ТОЙОТА" и "ТАЙОТА" , "VOLKSWAGEN" и "FOLKSVAGEN"...\r
- т.е у похожих названий на английском или русском языке отличаются макс.на 1-2 буквы.\r
---\r
Решение: \r
создать интерфейс пользователя и валидатор для вводимых в справочник названий фирм-производителей, чтобы вводимые названия удовлетворяли требованиям 1-4. См. Вариант 2. Интерфейс: в режиме просмотра справочник показывает название, например, в виде "TOYOTA / ТОЙОТА", в режиме редактирования используются 2 поля с валидацией данных, вводимых на том или ином языке\r
\r
изначально я поставляю заполненные справочники фирм производителей и моделей авто \r
\r
но к примеру звонит продавец с РОЛЛС-РОЙСом и просит принять его объявление \r
а такой модели и фирмы производителя нет, \r
варианты которые я увидел: ......... \r
\r
Я также согласен со "StarWind" иначе будет бардак. Что касается РОЛЛС-РОЙСа, ЛАМБАРГИНИ или Т-34, то их можно просто не учитывать. Можно также создать, например, "Эксклюзивные фирмы-производители" куда можно добавлять названия таких фирм-производителей. Это действительно облегчит жизнь девушкам на телефоне когда случаются такие объявления

2 Groove:
Но проблема заключалась не в валидации или хранении информации в Slave-базах (организаций), если их так можно назвать, а в слиянии Slave-баз в мастер-базу у меня на сайте

Я же хотел, чтобы было все по правилам, полновесная реляционная Master-БД, а не однотабличная.

А в чем проблема, если у всех организаций будут единые правила заполнения справочника? Если у вас в каждой Slave будет соблюдаться целостность, то это без разницы сколько cливать или реплицировать таблиц/справочников с классификаторами в Master

1. Я должен сделать БД из одной таблицы вида
...
и отказаться от классификатора

Зачем? Механизм синхронизации классификатора в Master и Slave даже для Варианта 3 использует те же идеи, что и в решении для Варианта 3 (для заполнения девушками в организации), а также к-рая ниже с диапазоном или GUID дя слияния/репликации

2. В организациях забирать вместе с таблицей свежих объявлений и сами справочники, а потом разработать конвертилку в Master-БД.

А какую СУБД вы используете?

Самую большую проблему я вижу в AUTO_INCREMENT полях и дальнейшем сопоставлении записей справочников в Slave к Master.

Если я пока правильно понимаю, то здесь вообще нет проблемы. Вы можете, например, разным Slave-БД назначить разные диапазоны с большим запасом для значений в столбце с AUTO_INCREMENT (т.е IDOrg,IDFirm,ID ). Тогда значения ID объявлений будут уникальны в своем диапазоне. Решение "топорное" потому что когда у вас закончятся значения в каком-то диапазоне (хотя это маловероятно для огромных диапазонов), то вам придется мудрить со вставкой. Вообще в вашем случае, наверное,ю лучше не связываться с AUTO_INCREMENT (IDENTITY):

MSSQL2000 BOL: If an identity column exists for a table with frequent deletions, gaps
can occur between identity values. If this is a concern, do not use the IDENTITY
property. However, to ensure that no gaps have been created or to fill an existing
gap, evaluate the existing identity values before explicitly entering one with
SET IDENTITY_INSERT ON.
....
Consider using the IDENTITY property when global uniqueness is not necessary, or
when having a serially incrementing key is desirable.

т.е в MSSQL вы бы могли использовать столбец uniqueidentifier (GUID) с DEFAULT newid()