• Вы можете объяснить, что такое четвертая нормальная форма так, чтобы было понятно?

    @grebenyukov
    В примере по ссылке на википедии - представьте, что у вас есть таблица с ресторанами, таблица с видами пиццы и таблица с районами доставки. Теперь Вам надо заложить в схему БД объекты для указания: а) в каком ресторане какой вид пиццы производят и б) из какого ресторана в какой район можно доставить. В примере рассмотрены 2 варианта - 1) таблица с полями (ид_ресторана, ид_вида_пиццы, ид_района_доставки) и 2) две таблицы, одна с полями (ид_ресторана, ид_вида_пиццы) и вторая с полями (ид_ресторана, ид_района_доставки) - и описано, почему первый вариант не в 4НФ. Суть в том, что при первом варианте реализации в БД возможны случаи, когда какие-то из ресторанов одни виды пицц могут поставлять в определенный районы, а другие виды пицц - не могут. Кроме этого, при добавлении нового вида пиццы, мало создать 1 элемент таблицы в справочнике и 1 элемент в таблице связи, а надо сделать это для всех районов доставки. И далее рассматривается другой случай, когда цена пиццы определяется как функция от ресторана, вида пиццы и района доставки (видимо. в этом примере стоимость доставки включена в стоимость пиццы). Вот для этого случая, из-за наличия функциональной зависимости, таблица с ценами будет иметь альтернативный ключ из трех полей как в примере 1) и этого уже не будет нарушением 4НФ.
    Вы можете не использовать первичные составные ключи. Однако, более-менее сложная система скорее всего будет иметь сущности с составными альтернативными ключами - если такой ключ не сделать, возможны логические дубли, составной альтернативный ключ в виде констрейна или уникального индекса убережет от этого. Например, когда в таблице связи ресторанов и видов пиццы будут 2 или более строки с одинаковым набором значений (ид_ресторана, ид_пиццы).
    Ответ написан
  • Где посмотреть примеры архитектур/связей БД?

    @grebenyukov
    Ищите по ключевому слову IDEF1X. Результатов с объяснениями и примерами масса, в т.ч., на русском. Все тут не перечислить.
    Ответ написан
  • В чём принципиальная разница двух запросов?

    @grebenyukov
    Будет разным количество столбцов, т.к. в первом случае select * производится из (подзапрос tt join таблица contacts_history), а во втором случае - только из таблицы contacts_history. То есть, в первом варианте будет плюс поле sclr_32.
    По производительности мне эмпирически больше нравится первый вариант, но как выше правильно написал SagePtr, надо смотреть план, причем с реалистичным количеством строк и соотношением количества строк к количеству уникальных значений поля contacts_history.contact_id.
    А если рассматривать применение подобных запросов на практике, то возможно, он еще будет обернут в select * from (...) limit xx offset yyy; Тогда и анализ надо будет проводить относительно полного текста. И тут мне кажется. первый вариант быстрее выдаст первые xx строк.
    Ответ написан