MasterZiv> Я вот подумал. У меня ресурс - уникальное значение. Один ресурс не может быть к
> разным Entity или Parameter. Поэтому зависимость получается M:1.
Так ты ресурс-то не бери, ресурс -- это у тебя уже для конкретного языка.
В общем, не важно.
Не понял, о чем Вы, можете расшифровать? :)
guest_20040621ТС, ваш вариант решения задачи плох.
Для корректной реализации вам нужно решить три задачи: метаописание экземпляров сущностей, _реляционная_ подстановка элементов и атрибутов, локализация (при существовании локализованных эквивалентов). MasterZiv предложил вам рабочую схему, но на практике вам будет сложно ее развивать.
Так я ж вроде как и иду по решению от MasterZiv. И где у меня плохо с описанными Вами тремя задачами?
MasterZiv
> varcharValue varchar(4096),
>
> Чем Ваше решение лучше?
Тогда либо для них надо вставлять в PK что -то типа специального идентификатора
языка, либо надо тоже выносить varcharValue в подтаблицу с языком в PK.
Ой, извините, забыл прибить это поле, конечно же, этого поля не будет, будет запись для каждого языка в таблице Resource.
MasterZivКроме этого, наверняка тебе захочется создать индексы на разные xxValue,
чтобы по ним можно было бы искать. Это уже тонкая материя, тут уже надо знать
о конкретике СУБД в реализации, но всё же, для каждого xxxVal в таблице
будет N записей (всего атрибутов), из них n будет этого значения,
а N-n будет NULL. Это может портить статистику и селективность. А может и не
портить.
Кстати да, действительно, я об этом раньше не задумывался... По идее, не должно портить, просто в статистике будет храниться информация о том, сколько там NULL значений. Как оно в реальной жизни будет, это конечно еще вопрос...
Если по таблице на каждый тип атрибута (date, int, varchar, text, float, boolean, char_id), так это вместо одного селекта будет семь, если брать данный случай. Вас не смущает такое количество лишних селектов? Это тоже может плохо сказаться на производительности. Та и закодить это сложнее будет
Вобщем, подумали мы, как сделать с тем, чтобы интернационализировать все таблицы, и придумали следующее решение:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
create table Resource(
id varchar(32),
varcharValue varchar(4096),
textValue text,
PRIMARY KEY (id)
);
create table Language(
id varchar(32),
name varchar(32),
PRIMARY KEY (id)
);
create table main.LanguageResource(
id varchar(32),
resourceId varchar(32) REFERENCES Resource(id),
languageId varchar(32) REFERENCES Language(id),
varcharValue varchar(4096),
textValue text,
PRIMARY KEY (id)
);
create table main.Attribute(
id varchar(32),
entityTypeId varchar(32) REFERENCES EntityType(id),
nameId varchar(32) REFERENCES Resource(id),
-- other fields
PRIMARY KEY (id)
);
create table main.Parameter(
entityId varchar(32) REFERENCES Entity(id),
attributeId varchar(32) REFERENCES Attribute(id),
stringValueId varchar(32) REFERENCES Resource(id),
integerValue integer,
floatValue float,
datetimeValue timestamp,
booleanValue boolean,
entityValue varchar(32) REFERENCES Entity(id),
PRIMARY KEY (entityId, attributeId)
);
Именно создание промежуточной таблицы Resource позволит нам не заводить по языковой таблице на каждую таблицу БД, или создавать по одному атрибуту на каждую таблицу в большой языковой таблице.
Также у нас будут разделы сайта, которые не нужно интернационализировать. Для этого случая мы вынесли varcharValue и textValue в таблицу Resource.
Что скажете насчет такого решения?
