Добрый день. Прошу знатоков выразить свое мнение ( и , желательно, подвердить мнение доводами) в таком вопросе. Многое мной было прочитано из организации таблиц, но к однозначному мнению в выборе я так и не смог придти. Есть две таблицы - Родительская и дочерняя. Родительская таблица имеет Prymary Key (number (20)) и еще несколько независимых столбцов с пороядка 1 000 000 записей. Дочерняя имеет всего три столбца (Foreign Key на материнскую таблицу, number (20), number (1) может принимать значения 0, 1 или 2 и могут меняться в процессе работы). В дочерной таблицы имееться много записей ( порядка по 1000 ) по каждому Foreign Key. Значения первого, второго и третьего столбца вместе организовуют уникальное значение. Суть вопроса заключаеться в следуещем: необходимо выбрать оптимальный вариант организации дочерной таблицы с учетом вот таких особенностей системы :

а) ожидаеться множество паралельных запросов трех видов :;1. выборка всего содержимого стольбца №2 принадлежащему одному конкретному Foreign Key и где значение стольбца №3 равно 0.; 2. выборка конкретного значения столбца №2, принадлежащему конкретному Foreign Key и где значение стольбца №3 равно 0.; 3. выборка значения столбца №3 принадлежащему одному конкретному Foreign Key и одному конкретному значению столбца №2.
б) интенсивное добавление новых записей.

Я склоняюсь к индекс-таблице по значения Foreign Key+Столбец№2. Но тогда сложно будет выполнять запрос №1 т.к. нет индекса по столбцу№3 плюс, не знаю, на сколько будет тормозить добавление новых записей.

Расматривал кластеризацию по ключам этих двух таблиц, но есть три проблемы: а)даные в дочерней таблице не будут по-порядку, что будет тормозить запрос №2 и№3 т.к. придеться сканить весь кластер. 2) Усложняет добавление новых записей. 3) Родительская таблица будет иметь связь не только с одной дочерной

В партировании меня смущает его непрямое назначение для увеличения производительности (тоест, целеобразно ли вобще).

Помогите разобраться в детялях и выбрать лучший вариант. От этого зависит успешность проэкта))) Заранее спасибо

Мимо крокодил,
Администрирование записей и урезание устаревшей инфы

Орфокл,
Большинство

Мимо крокодил, распределение даных очень резонансное 0- 80%, 1 - 18% , 2 - 2%

Мимо крокодилавторАдминистрирование записей и урезание устаревшей инфы
И увеличение производительности, причем, оно ИМХО на 1м месте.

Если партиционировать по листу по 3му полю, сделать локальный составной индекс по 1 и 2 полю, то для выполнения 1го запроса будет читаться только индекс. По 2му запросу вопрос - зачем искать строку все поля которой в фильтре? - на предмет существования? если да - то тоже прочитается только индекс. В 3м запросе - кардинальность - 3, доступ по rowid.
Нюансы - деградация вставки из-за индекса и деградация апдейта из-за партиционирования - это нужно тестить, устроит ли

Третье поле может и будет меняться

Подскажите, каким образом СУБД ищет необходимую партицию? Есть ли разница в скорости поиска названии таблицы или названии партиции? Скорость вставки даных в существующюю партицию или в таблицу. Насколько мне извесно: механизм обслуживания партиций и механизм обслуживания таблиц очень похож. И там аи там - это отдельный сегмент

LemkolegДобрый день. Прошу знатоков выразить свое мнение ( и , желательно, подвердить мнение доводами) в таком вопросе. Многое мной было прочитано из организации таблиц, но к однозначному мнению в выборе я так и не смог придти. Есть две таблицы - Родительская и дочерняя. Родительская таблица имеет Prymary Key (number (20)) и еще несколько независимых столбцов с пороядка 1 000 000 записей. Дочерняя имеет всего три столбца (Foreign Key на материнскую таблицу, number (20), number (1) может принимать значения 0, 1 или 2 и могут меняться в процессе работы). В дочерной таблицы имееться много записей ( порядка по 1000 ) по каждому Foreign Key. Значения первого, второго и третьего столбца вместе организовуют уникальное значение. Суть вопроса заключаеться в следуещем: необходимо выбрать оптимальный вариант организации дочерной таблицы с учетом вот таких особенностей системы :

а) ожидаеться множество паралельных запросов трех видов :;1. выборка всего содержимого стольбца №2 принадлежащему одному конкретному Foreign Key и где значение стольбца №3 равно 0.; 2. выборка конкретного значения столбца №2, принадлежащему конкретному Foreign Key и где значение стольбца №3 равно 0.; 3. выборка значения столбца №3 принадлежащему одному конкретному Foreign Key и одному конкретному значению столбца №2.
б) интенсивное добавление новых записей.

Я склоняюсь к индекс-таблице по значения Foreign Key+Столбец№2. Но тогда сложно будет выполнять запрос №1 т.к. нет индекса по столбцу№3 плюс, не знаю, на сколько будет тормозить добавление новых записей.

Расматривал кластеризацию по ключам этих двух таблиц, но есть три проблемы: а)даные в дочерней таблице не будут по-порядку, что будет тормозить запрос №2 и№3 т.к. придеться сканить весь кластер. 2) Усложняет добавление новых записей. 3) Родительская таблица будет иметь связь не только с одной дочерной

В партировании меня смущает его непрямое назначение для увеличения производительности (тоест, целеобразно ли вобще).

Помогите разобраться в детялях и выбрать лучший вариант. От этого зависит успешность проэкта))) Заранее спасибо

Небольшое уточнение: Уникальность записей будет распространяться по первым двум столбцам

Мимо крокодилLemkolegТретье поле может и будет меняться

Да, я прочитал. Вопрос в том, будет ли эта деградация заметна и влиять на работу приложения. Так как понятие "интенсивности" и возможности железа все-таки индивидуальны. Для этого нужно тестировать.
Не интенсивно

Мимо крокодилLemkoleg,

Чтобы далеко не ходить:



Я вкурсе, что обновления в партицировании ( изменяющее партицию) равносильно удалении и добавлении вместе взятых.

DВА,
Он несет только информативность первых двух. Если человеческим языком: В каждом приюте (родительская таблица) может быть по несколько тысяч собак (столбец№2 дочерней таблицы). Каждая из них либо: привитая, либо не привитая, либо не нуждаеться в прививке (столбец №3). Не может одна из них быть и привита и не привиты одновременно. Все (большинство) даных будут актуальны. Тоесть, вопрос об их отсичении пока не расматриваеться

Неисключено.

Rudyshin Sergey, спасибо