Серега

Зато с одной таблицей работать проще и производительнее (как правило). Нужно (например) поддерживать меньше индексов. Т.е. при вставке будет обновляться 1 индекс, а не 2 - при больших объемах здорово быстее. Да и на постоянном объединении 2 таблиц можно здорово проиграть в скорости.

С этим можно согласиться только с оговоркой: нам необходимы всегда все данные при запросе, другие запросы не используют данные из этой таблицы. Логичнее было бы разбить данные на несколько таблиц по некоторым определяющим признакам и запросами собирать их. Если нам нужна только часть данных, то перелопатить две таблицы будет легче, чем одну содержащую в три раза больше данных чем эти две. Но все это зависит от конкретной задачи.
По поводу места. Место даже может быть сэкономлено. За счет того, что у меньшего количества полей меньше длина строки и, соответственно, мы можем поиграться параметрами PCTFree и PCTUsed, в сторону увеличения заполнения блока. Да и про сцепление строк при частых удалениях, изменениях, вставке забывать не стоит - а это уже производительность.

Это я про оракл :)

Серега
2Jinn
>Если нам нужна только часть данных, то перелопатить две таблицы будет легче, чем одну содержащую в три раза больше данных чем эти две.
С чего бы это при наличии индекса на поле поиска?

С того, что блоки с данными все равно придется считывать с диска, даже при наличии индекса. При этом считываются не только нужные в запросе, но и все остальные. Индекс всего лишь указатель на то, где эти данные взять.

>Это я про оракл :)
Ну если про него говорить, то там еще такая фича есть как кластеризованные таблицы. И если есть например поле дата, то разбив по ней эту таблицу мы получим офигенный выигрышь в скорости, так как оракл будет читать данные только из соответствующей части таблицы.

Немного не понял. Ты имеешь в виду кластеры или партицированные таблицы? Если последние - то разбивка по полю дата не самый лучший вариант, хотя дату для разбивки можно использовать для указания партиции применяя несложный алгоритм. В то же время данные могут потребоваться из разных партиций, так что выигрыш будет невелик.

Серега

Да пробовать надо, так на 100% не посоветуешь.

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

>Немного не понял. Ты имеешь в виду кластеры или партицированные таблицы? Если последние
Их родимых. Сори за неправильное выражение. Не работал с ними, только читал.

>В то же время данные могут потребоваться из разных партиций, так что выигрыш будет невелик.
Но не из всех же сразу. Наверное чаще всего запрашиваются недавние данные. А запросы типа "дай все что есть, а я тут посмотрю" чего хочешь уронят.

Выигрыш от партицирования таблиц, для запросов, незначителен или отсутствует при наличии индексов. Проявляется он в другом: оптимизация удаления данных (вместо delete используем truncate), возможность расположения одной таблицы в разных таблспейсах (на разных дисках). Очень выгодно применять для хранения больших объемов информации с конечным сроком хранения (бухгалтерия, биллинговые системы, сбор данных etc.)