Про базы данных

> Подскажи мне, вдруг я чего-то не знаю - как выяснить с первого взгляда, на какую таблицу ссылается поле DERIVATIVE_ID, если нет таблицы DERIATIVE?

Что значит ссылается? Внешний ключ что-ли? В phpmyadmin видно.

> Что значит ссылается? Внешний ключ что-ли?

Он самый

> В phpmyadmin видно.

Веб-поделками стараюсь не пользоваться.
В Toad for MySQL и в MySQL Workbench именно зависимостей не видно. FK - есть, можно глянуть. Но в том же IB Expert это сделано куда удобнее.

> А ничего, что СУБД определяется конкретной задачей?

С этом спорить не буду.
Но изучать надо то, где порог вхождения выше. Это если начинаешь, а вопрос был именно об этом, если я правильно понял.

[censored]

Как быть?

> А с чего лучше начать изучение с PostgreSQL или MySQL?

с SQL92 =)

комрад, я например занимаюсь электричеством и мне кажется вот такого типа ссылка будет интересна не только узкому специалисту.
[censored]
В то же время если я захочу обсудить проблему переходных процессов в сетях с изолированной нейтралью, то на вотт.ру я точно не пойду за советом, хотя уверен, что коллеги тут есть и возможно даже завяжется дискуссия :)

> Нормальные формы эт конечно удобно и красиво. Но ждать выполнения запроса с 3-5 join'ами на таблицах с сотнями тысяч записей несколько грустно.

А какой смысл в таких массовых выборках?

Советы прочитал, несколько интересных моментов явно пригодятся, так что спасибо.

Спорные моменты:
1) Именно слово CAPTION как-то не очень - в переводе это "заголовок" или "подпись". Я бы предпочел "CODE" для сущностей с уникальным строковым идентификатором и "TITLE" - с неуникальным. Следует также иметь в виду, что данная БД может быть использована одновременно пользователями/программистами из разных стран и для малазийского кодера писать запрос вида "SELECT * FROM TABLE WHERE CAPTION = 'Киев'" - с кириллицей в условии - будет немного затруднительно).
2) В качестве имени таблицы лучше использовать множественное число, а не единственное. Естественнее выглядит запрос: SELECT ID FROM USERS WHERE CODE = 'Петро Гавнюк'.
3) Работа с таблицами исключительно через представления / хранимые процедуры логична, если вся бизнес-логика инкапсулирована в БД (т.е. имеем двухслойное приложение БД-клиент). Если же приложение трехслойное и бизнес-логика реализована отдельным (серверным) слоем, то БД - просто хранилище данных, а слой бизнес-логики в идеале должен реализовывать возможность автоматического создания нового хранилища выбранного типа "с нуля". Серьезные ORM (Hibernate/Nhibernate) это умеют для различных СУБД. В этом случае БД - набор таблиц и средств обеспечения целостности (ключи, условия на столбцы, триггеры), а хранимые процедуры особо и не нужны.
4) Совет из личного опыта про пару таблиц LIST_TYPES и LISTS, пмсм, вреден. Таблицы БД описывают сущности и взаимоотношения между ними, а данные в таблицах - экземпляры сущностей. Т.о. совет п.9.1. предлагает смешать сущности и их данные в одной куче. В общем случае, пмсм, лучше для каждой сущности создавать свою таблицу (Работы, Оборудование, Контрагенты, ...) и для всех справочных таблиц использовать одинаковый префикс при именовании (DIC_WORKTYPES, DIC_EQUPMENT, ...). Это, среди прочего, позволит избежать лишних условий в представлениях (а-ля SELECT ID, CAPTION FROM LISTS WHERE LIST_TYPES_ID = 12 // улицы).
Модель, когда наборы разных сущностей укладываются в две таблицы, очень удобна для ряда специфических случаев, а без особой потребности ее лучше избегать (см. выше). Пример такого случая: в приложении по учету домашних финансов нужно классифицировать покупки по категориям, причем категории могут содержать подкатегории (напр. еда - молокопродукты - сыры - твердые сыры), а пользователь добавляет категории в процессе работы. Заводить динамически отдельные таблицы для "еда", "молокопродукты" и т.п. тупо, модель из двух таблиц - самое то. Кстати, смешения сущностей и их содержания в этом случае не происходит - есть сущность "Покупка" и сущность "Категория покупки", описываемые соотв. таблицами БД.

> А что не сразу всю базу в одну таблицу?

А почему бы и нет? Денормализация доведённая до логического конца))

>> А что не сразу всю базу в одну таблицу?

> А почему бы и нет? Денормализация доведённая до логического конца))

Дисков не напасешься!

> Вы [все] ещё не видели выборки из объектно-ориентированных БД с 10-кратным уровнем наследования!

Если чо.

> Собственно у нас обычно программистов заставляют немного на собственной программе поработать на целевой машине, на оптимизацию влияет просто мистическим образом)

Там у вас хорошо. А когда продукт уже куплен, как у меня, и его надо расширять, а документации по системе нет, поддержки нет, схемы данных нет - добиться мистической оптимизации невозможно. [Уныло грустит]. Самого заставили работать!!! [Грустит ещё сильнее]. Само собой, схема данных в нужном объёме была восстановлена, нужные запросы - написаны. Но осадочек-то остался!!! :)

Это уже специфика работы с большими объемами данных, и тут все зависит от конкретных задач.

> И что говорит план запроса? Может, каких-то нужных индексов нет, и где-то выполняется full scan?

Индексы есть конечно. Вроде все, какие нужны. Поэтому всего лишь грустно :)

> Собственно у нас обычно программистов заставляют немного на собственной программе поработать на целевой машине, на оптимизацию влияет просто мистическим образом)

Это да. Полезная штука.

> Индексы есть конечно. Вроде все, какие нужны. Поэтому всего лишь грустно :)

Ну, если оптимизатор больше не предлагает построить индексы, есть ещё один вариант: выполнение запроса в несколько этапов с сохранением промежуточных результатов во временных таблицах и/или использование аналитических функций.

> Ну, если оптимизатор больше не предлагает построить индексы, есть ещё один вариант: выполнение запроса в несколько этапов с сохранением промежуточных результатов во временных таблицах и/или использование аналитических функций.

Грустно - это 3-5-10 секунд. Для основного списка пришлось продублировать часть информации прямо в документе.

> Грустно - это 3-5-10 секунд. Для основного списка пришлось продублировать часть информации прямо в документе.

наш клиент решил подобную проблему переносом базы на ссд рейд :)

> Это неспортивно !!!

ну, на таблице с 120+ млн записей другого выбора не было. Кстати, ради пёрфоманса, пршилось всё пихать в одну таблицу мега денормализованную, ибо джойны на таких количествах тоже офигевали.

> Да тыж, небось, нас обмануть хочешь!!! У этиого клиента, надо полагать, какая-нибудь специфическая информационная система, которая обновляется раз в неделю, а всё остальное время 24/7 отвечает клиентам на один и тот же запрос с точностью до параметров!

система специализированная, да, только наполняется 24/7 и отвечает клиентам 24/7, причём запросы на чтение от клиентов могут идти произвольные, все что только можно кэшируется на стороне вебсайта, но всё равно нагрузка на базу ого-го. Мейнтенс окно 1 час, все индексы приходится ребилдить в онлайне, чтобы обновление 24/7 было (МС СКЛ фича), а ещё эту таблицу надо успеть почистить от устаревших записей(привет, фрагментация индексов) и сгенерировать данные для таблиц промежуточных, ну тех, о которых ты говоришь, некоторые данные таки можно приготовить. А некоторые - нет, нужно выдавать свежие :).

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