> Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам.Ну не обязательно именно дискам.
Старая как мир плюшка - ручное разбиение высоконагруженной таблицы ABC на N идентичных по структуре таблиц ABC00..ABCn с выборкой конкретной таблицы по какому то простому признаку скажем от primary key. Иногда это позволяет в разы а иногда и на порядки снизить общую нагрузку на базу, если ABC является бутылочным горлышком. Банально из-за снижения вероятности ожидания на блокировке.
Однако, возникает и естественное неудобство при работе с такой вот вручную разбитой 'таблицей'. Особенно, если требуется сделать какую то выборку из всей таблицы. Именно тут IMHO partitioning на уровне RDBMS был бы как нельзя кстати - и волки сыты и овцы целы. Конечно, вопрос об конечной эффективности встроенного разбиения могут показать лишь тесты и работа на реальной системе, но все предпосылки налицо.
Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен.
> Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.
'Тот объем данных' - понятие сильно растяжимое. Все может радостно встать колом практически независимо от железа даже на каких то 1M записей в несложной табличке, если к ней ведётся разношерстный параллельный доступ на чтение/модификацию.
Отказ же от внешних ключей и перенос контроля за целостностью базы на уровень приложения лишь потому, что 'почему то все тормозит' - это совершенно не аргумент при дизайне системы. Разве что камень в огород конкретной RDBMS.
