Ответы пользователя по тегу SQL
  • Правильно ли ставить внешние ключи на поле ID?

    alekciy
    @alekciy
    Вёбных дел мастер
    Судя по всему у вас id это суррогатный PK. Есть есть уникальное поле field1, то держать в таблице суррогатный PK имеет смысл только ради удобства человека, в остальном он совершенно не нужен. С таблицей 2 ситуация аналогичная.

    Как правильно организовать связь между таблицами?

    Если один-ко-многим, то поля table1_field1 достаточно.

    Будет ли разница между внешним ключом

    О какой разнице речь? В такой формулировке как у вас, то нет, не будет.

    id - цифровое, а field1 - строковое поле. Это может иметь значение?

    field1 случайно не UUID? В большинстве случаев разницы не будет. Все равно на них вешать индекс.
    Ответ написан
  • Какие реализации могут быстро искать пересечение множеств (система тегов)?

    alekciy
    @alekciy Автор вопроса
    Вёбных дел мастер
    Оставлю как ремарку для истории. На данный момент схема в sphinx получается самой быстрой. Вопрос с дельта индексом решился просто более частым его пересчетом. Теперь приложение следит за его размеров и как только в нем больше 20к документов, запускается ротирование. Получается требуемая быстрота выборки даже на сложных запросах.
    Ответ написан
  • Дамп базы mysql

    alekciy
    @alekciy
    Вёбных дел мастер
    mysqldump -uUSER -pPASSWORD -hlocalhost -d --default-character-set=utf8 --quote-names --allow-keywords --add-drop-table --set-charset schema_info > /path/to/file/schema.mysql

    mysqldump -uUSER -pPASSWORD -hlocalhost -d --default-character-set=utf8 --quote-names --allow-keywords --add-drop-table --set-charset --ignore-table=schema_info > /path/to/file/schema.mysql

    man mysqldump
    Ответ написан
  • Многоязычный сайт… не блог… как?

    alekciy
    @alekciy
    Вёбных дел мастер
    Не понимаю, зачем все так усложнять, когда все укладывается в простую схему. Весь контент сайта условно можно разделить на 3 части:
    1) редко меняющиеся данные (они обычно зашиты в файла шаблона);
    2) часто меняющие данные либо контент генерируемый пользователями/администраторами/модераторами;
    3) бинарные данные в духе картинок, прикрепляемых файлов.

    Вся статика находится в папке skin/имя_скина/цветовая_схема/язык (например, /skin/modern/red/ru, у меня по умолчанию /skin/default/default/ru), в базе любой текстовой контент требующий перевода имеет столбцы под каждый требуемый целевой язык. Это могут быть столбцы с постфиксом оригинальное_имя_язык (к примеру, topic_content, topic_content_ru) для mysql или же наследование таблиц из postgresql.

    Реализация:
    1) вся текстовая информация сосредотачивается в файлах шаблона с использованием gettext-а.
    2) постфиксные столбцы во всех таблицах.
    3) статические картинки связанные со скином распределены по языковым папкам, адреса же до динамически добавляемых картинок хранятся в базе и при запросе согласно п.2 получаем адрес до нужной языковой картинки.

    Единственная трудность с которой тут можно столкнуться, это gettext и переводы требующие контекста. Поскольку переводчик на руки получает po файл, то он не знает, на какой странице сайта используется то или иное слово и какой у него контекст. Но это не очень частый случай и просто требует привлечение к работе разработчика.
    Ответ написан
  • В чем принципиальное отличие unique (constraints) от unique index?

    alekciy
    @alekciy
    Вёбных дел мастер
    Разница в том, что ограничения (сonstraints) призваны обеспечивать целостность данных, а индексы (index) — скорость доступа к данным. Это две абсолютно не связанные сущности. Причем если первое — часть SQL стандарта, то второе нет (ибо ни как не связанно с функциональностью языка, введение индексов — вынужденная мера). Разработчик сам решает, в каких случая применить эти механизмы и использование одного вовсе не требует использование другого.

    Теперь касательно уникальности (unique). В данном случае при добавлении ограничения уникальности (unique constraint) Postgresql сам навешивает на указанное поле индекс. Это просто особенность реализации в данной СУБД. Разработчики решили, что вот так оно будет работать и все тут (причем небезосновательно). В другой же схожей ситуации они решили, что разработчик сам думает, нужно ли ему использовать этих два механизма вместе, или нет. Я говорю об ограничении целостности по внешнему ключу (foreign key). В Postgresql индексы по полям с данным видом ограничения не создаются (Индексы по внешним ключам в Postgresql). А, к примеру, в MySQL создаются. Это особенность реализации в MySQL.

    Поэтому важно просто понимать, что это не связанные вещи, просто в некоторых реализациях они «сцеплены» между собой и создание некоторых видов ограничений приводит к автоматическому созданию индекса.
    Ответ написан
  • Альтернатива EAV, структура базы?

    alekciy
    @alekciy
    Вёбных дел мастер
    Структура базы. На тестах 250 тыс. товаров с 10 тыс. параметров (10 параметров на один товар) отрабатывает менее чем за 1 мс на posgresql, так что самым тормозным местом будет явно не база.

    >Хотелось бы знать, чем же все таки это плохо.
    Ни чего плохого в EAV нет. Если под текущий размер базы выделены достаточные аппаратные ресурсы и в базе в нормальном виде расставлены индексы, то самым тормозным местом будет явно не база. Так что «советчиков» которые без конкретных аргументов так говорят можно сразу спокойно слать лесом.
    Ответ написан
  • Redis vs SQLite vs PostgreSQL

    alekciy
    @alekciy
    Вёбных дел мастер
    >В чём же тогда прелесть Redis-а?
    Данные всегда в ОЗУ, когда как в РСУБД индекс может быть вытесняться на диск, данные при этом на больших объемах почти всегда на диске. Поэтому и получаем просадку производительности из-за I/O на диске. В Redis это в принципе нет, они сейчас на сколько я помню от виртуальной памяти отказались. Про О(1) Ghostwriter уже сказал. ACID таки вносит свой оверхед.

    Ну и из подобной группы ПО его выделяет условная персистентность.
    Ответ написан