Здравствуйте. Мы пишем проект на Django и в кчестве СУБД используем ORACLE.

Во время проектировки мы решили создать не стандартную модель, это значит что у нас есть:

1.Главная таблица Items
2. Наследуюшие таблицы(Forgein Key на Item) которые являются разными сущностями (Category, Product и т.д)
3. Таблица со списком атрибутов
4. таблица Values :


^{CREATE TABLE "TPPDB"."CORE_VALUE"
( "ID" NUMBER(11,0),
"TITLE" NCLOB,
"ATTR_ID" NUMBER(11,0), -- Ссылка на атрибут
"ITEM_ID" NUMBER(11,0), -- Ссылка на Item
"SHA1_CODE" NVARCHAR2(40),
"START_DATE" TIMESTAMP (6) DEFAULT NULL,
"END_DATE" TIMESTAMP (6) DEFAULT NULL,
"CREATE_DATE" TIMESTAMP (6) DEFAULT NULL,
"CREATE_USER_ID" NUMBER(11,0) DEFAULT NULL
)}


Title - Значение атрибута.

Меня беспокоит то что он является NCLOB т.к там могут хранится длинные тексты. Но вопрос как сама БД с этим работает т.к 70% - 80% будут максимум в 100 символов.

Кроме того таких полей около 10(я их не указал) т.к они созданы под каждый язык.

Что посоветуйте делать? Оставить всё как есть или длинные тексты вынести в другое место и если да то как?

Спасибо!

softwarer Можно узнать по какой причине умрет?

Стараемся делать всё правильно на AWS

ELB + пару EC2 + Memcache servers + Oracle instances multi AZ + S3

Вот только специфика проекта такая что проектировать нужно было не стандартно.

Если у вас будут советы , с радостью послушаю.

Shtock
Не стоит придираться к словам, если бы не было бы здравого смысла, не возникло бы вопроса.

Во вторых , возможность масштабирования это одна из вещей о которой не стоит забывать, это то что мы видели на многих соц сетях которые по мере роста популярности спасались только масштабированием(когда архитектура хромала).

В третьих, это ответ на вопрос, то что как раз я и ждал в это теме а не пустые насмешки. Oracle (Может и другие) создают стеки + индексы на поля типа CLOB , размер стека можно определить, тем самым он выделает количество памяти в зависимости от размера стека и их количества, а стеки создаются в зависимости от количества данных в колонке.

Краткое описание задачи:
1. Есть множество сущностей (Продукты, категории, компании, новости, и т.д около 40) нужна возможность связывать любые сущности друг с другом и с самими с собой.

2. Привязка может менять статусы и от этого менять права доступа.

3. Привязка может быть иерархической

4. Привязано может быть N`ое количество сущности к другой.

5. У каждой сущности могут быть атрибуты

6. Атрибуты сущностный могут отличатся

7. Экземпляры одной сущности могут иметь разные атрибуты

Это короткое описание части задания.

Если будут более разумные предложения, с радостью выслушаю.

Если кому интересно, вот диаграмма

SERG1257 Вот ещё один которому колит глаза аббревиатура AWS , последнее вы были обязаны добавить да? Не сдержались? =)
Но спасибо за ответ посмотрю.

П.с не нашел как редактировать сообщения на форуме, вот ссылка на диаграмму . может я плохо выражаюсь

SERG1257DDeath Если кому интересно, вот диаграммаСкажите, вы правда ничего не поняли или просто издеваетесь?

Послушайте, я выложил диаграмму т.к плохо выражаю мысль , и для того чтоб мы говорили но одном языке показываю наглядно то что у меня есть. Почему вы так нервничаете? =)

П.с ещё раз спасибо!

Dimitry Sibiryakov Ох уж спасибо пряморуким Форумчанинам, как же без вас. Вот только это то что вы и описали , только для более удобной разработки(Да я знаю , в ущерб производительности) Django делает таблицы для всех типов сущностей. Но вопрос был не в этом, благодарю вас О пряморукий форумчанин, можете идти дальше, большое вам спасибо!

SERG1257 Я прошу прошения, я действительно плохо выражаю мысли и плюс ко всему я не из России и мой русский ужасен.
Но я постараюсь объяснить для того чтобы вы смогли мне помочь.

У нас совмещается в проекте большое количество под проектов будь то магазин , бизнес площадка, площадка для поиска работы и т.д и всё это должно быть в одной базе и перевязано между собой. Изначально архитектура планировалась такая как описал Dimitry Sibiryakov , но т.к джанго в ущерб производительности дает другие инструменты мы решили создать под каждую сущность таблицу(Модель). Проблема возникла тогда , когда нам нужно было создавать атрибуты для сущностей и давать им значения и мы решили взять сделать её по типу EAV (хотя тогда и не знали что это такое), когда возникла задача сортировать по значению атрибута, оракл ругнулся что тип NCLOB не сортируем (но это было решено с помощью CAST и TO_NUMERIC) и тогда же, меня начало это беспокоить, я понял что оракл относится к этому типу полей по другому и я хотел выяснить как использование NCLOB может сказаться на производительности при том что у этого поля есть дубляж для каждого языка. А так же надеялся что мне смогут предложить замену EAV или хотя бы частичную замену.

П.с я не DBA и не архитектор а просто программист, по части БД я мало что знаю.

П.с.с надеюсь я описал всё более или менее понятно.

rockclimber Dimitry Sibiryakov Меня смущает то что вы не знаете условий задачи поставленной перед нашей командой и начинаете хаить. Если выбор пал на джангу значит таковы условия, мой вопрос в другом...

SERG1257 Опять 25, я тут значит я хочу услышать мнения, и узнать...

SERG1257см пост от _мод, только уточню, что наверное не varchar2, а nvarchar2 для значений втискивающихся в 4000 символов. Для более длинных значений, пусть клиент идет за добавкой в дополнительную таблицу, например найдя в конце TITLE - "продолжение следует".


Я учту спасибо, мне предлагали вариант хранения в NoSql типа MongoDB но вот что делать с привязкой к объекту...