Четверг , 28 Март 2024
ДомойПубликациикраткое сравнение баз данных: MySQL, PostgreSQL, SQLite, FireBird. Part 1

краткое сравнение баз данных: MySQL, PostgreSQL, SQLite, FireBird. Part 1

СУБД: MySQL, PostgreSQL, SQLite, FireBird

третьего дня мой воспалённый повышенным относительно средней части народонаселения мозг воззвал, и я его услышал. воззывание касалось систем управления базами данных (в народе чаще просто именуемых БД), хотя бы на уровне сравнения некоторых из них. некоторое время назад был похожий опус, касаемо небольшого сравнения php и perl.

отчасти на сей подвиг меня сподвигли разного рода холивары, в большинстве из которых mysql выставляется как одна из самых тормознутых баз в славном семействе субд. откровенно говоря, смешно слышать такие замечания от людей, суточная суммарная посещаемость сайтов которых не превышает 200 уников. и со всей ответственностью могу заявить, что даже если количестве посетителей будет в 100 раз большим, сайт будет прекрасно крутиться на файлах при не самой опитимальной структуре хранения информации. но оставлю размышления на отстранённую тему и сосредоточусь на основной мысле статьи.

в обзор попали следующие базы данных: MySQL, PostgreSQL, FireBird, SQLite.

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

первое, что требуется сделать с предоставленной базой, создать таблицы. для теста была взята простейшая структура: уникальное автоинкрементируемое поле + поле текстовое. текстовым полем может являться что-то, типа CHAR, VARCHAR или TEXT.

-- MySQL
CREATE TABLE catalog (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    name TEXT
);

-- SQLite
CREATE TABLE catalog (
    id INTEGER PRIMARY KEY,
    name TEXT
);

-- PostgreSQL
CREATE TABLE catalog (
    id SERIAL PRIMARY KEY,
    name TEXT
);

-- FireBird
CREATE TABLE catalog (
    id INT PRIMARY KEY,
    name BLOB SUB_TYPE TEXT
);
CREATE SEQUENCE id_catalog;

что ж, даже такая простейшая структура таблицы выявляет пачку отличий. для начала, отчего первичное автоинкрементируемое поле везде объявляется по разному (а в случае с FireBird такого поля даже нет!)? “ножки” растут из описания языка sql, в котором почему-то не уделено вниманию автоинкрементируемых полей как данности. да, как бы парадоксально это не звучало, так оно и есть. благодаря такой «оплошности», в FireBird для этих целей приходится создавать генератор (использование которого аукается некоторыми весьма неприятными последствиями). в остальных рассматриваемых субд этому вопросу всё-таки уделено внимание. так, в PostgreSQL существует специальный тип SERIAL, а SQLite полагает, что целый первичный ключ и является автоинкрементируемым значением. самое простое и универсальное решение для присвоения очередного уникального порядкового номера выглядит так:

INSERT INTO catalog (name) VALUES('text value');

однако в FireBird этот трюк не работает. как видно из примеров создания таблиц, для этого поля введён некий генератор. т. е., чтобы всё-таки получить очередное уникальное значение, сначала потребуется увеличить значение генератора:

SELECT NEXT VALUE FOR id_catalogs FROM RDB$DATABASE;
-- этот результат получает приложение и уже с ним генерит второй запрос
INSERT INTO catalog VALUES(, 'text value');

следующее поле тоже выявило несколько отличий. так, в MySQL максимально возможная длина добавляемых данных — 65535 байт. в PostgreSQL и SQLite эти значения значительно больше (в MySQL, кстати, можно спокойно использовать MEDIUMTEXT или LONGTEXT, увеличив, таким образом, значение хранимых данных “до безобразия”). но сейчас не об этом, итак, получение данных:

SELECT * FROM catalog WHERE id = 1;

каждая из субд прекрасно справилась с заданием, вернув требуемые значения, кроме того же самого FireBird, в котором вместо ожидаемого текста возвращается идентификатор, с помощью которого (и дополнительного запроса!) можно получить значение поля. а если всё-таки нужно получать текст, то полю назнается другой тип: VARCHAR(32765). но! 32765 — это максимальное количество байт, которое может быть размещено. т. е. при использовании UTF-8 максимальное количество символов составит 10921. для большинство случаев, пожалуй, хватит, но для серьёзного форума уже придётся вводить ограничение на максимальную длину сообщения. вроде бы пустяк, но всё-равно не очень приятно. собственно, после этого данную субд я, от греха подальше, снёс, и оставшееся тестирование уже проводилось на 3 субд.

Рейтинг: 0

Автор публикации

2 070
не в сети 11 месяцев

x64 (aka andi)

Комментарии: 2893Публикации: 405Регистрация: 02-04-2009
Так себеНеплохоХорошоЗамечательноСупер! (Оценок пока нет)
Загрузка...

22 комментария

  1. Неправильная работа с firebird!

    «SELECT * FROM catalog WHERE id = 1;
    в котором вместо ожидаемого текста возвращается идентификатор» (c)
    Прикладное ПО никогда не видит этот идентификатор (BLOB_ID)! Оно просто считывает байты из потока InputStream, который ему открывает драйвер(Jaybird, FBPlus, IBExpress и т.д.). И храните в BLOB хоть гигабайты вашего текста.

    «если всё-таки нужно получать текст» — если вы уверены, что там строка меньше 32 кБ и у вас в определении BLOB SUB_TYPE 1, то можно читать это как текстовое поле без проблем:

    Delphi:
    var
    name: String;
    begin
    IBQuery1.setText(«SELECT name FROM catalog WHERE id = 1»);

    name := IBQuery1.FieldByName(«name»).asString;

    end;

    JDBC (Jaybird) :

    String name = resultSet.getString(«name»);

    Всё будет работать. И на запись тоже!:
    Delphi
    IBQuery1.ParamByName(«name»).AsString = «my new string»;
    Java
    preparedStatement.setString(index, new String(«my new string»));

    Если у вас предполагается хранить строки больше 32 кБ, то не делайте так никогда! Это на вашей совести, а не на совести Firebird. Читайте данные из потока и записывайте в поток (stream). Это более грамотно.

    Насчет автоинкремента.
    Генератор дает новое значение вне контекста транзакции, что гарантирует уникальность значения? кто бы и как бы не обращался к генератору. С помощью триггеров и ХП можно очень гибко управлять значением поля PRIMARY KEY. Один генератор можно использовать для нескольких таблиц. Можно задавать диапазоны значений уникального ключа. Можно задавать шаг. Иногда это нужно, например, если у вас есть центральная (головная) бд и бд филиалов, где у каждого филиала свой диапазон PRIMARY KEY таблицы CATALOG. После репликации данные из филиалов сливаются в центральную БД без исключений из-за совпадения ID.
    К тому же, в новой версии FB можно делать запрос сразу к нескольким БД, что требует при вставке нвоой записи использовать диапазоны у каждого генератора на каждой базе, либо делать один запрос к селективной ХП, выдающей новое значение генератора ведущей базы.

    Рейтинг: 0
  2. Уточнение:
    VARCHAR(n), где n — максимальное кол-во символов, а не размер в байтах.

    Рейтинг: 0
  3. Vasyan,
    по поводу прикладного ПО, которое никогда не видит этот идентификатор, я точно не знаю (это нужно рассматривать исходный код драйвера), поэтому пишу так, как дело обстоит в php: в результате возвращается идентификатор, который нужно использовать для получение текста.
    по поводу строки меньше 32 кБ: Вы ничего не путаете? насколько я понял, это общий размер (т. е. в cp1251 будет 32 кБ символов, а для utf-8 символов получится в 3 раза меньше). таким образом, получим немного не то, что требуется.
    ну и насчёт автоинкремента: я не говорю, что триггеры это плохо. в некоторых случаях они удобны (как в Вашем примере). но касаемо, допустим, веб-форума, где есть топики, темы, сообщения, пользователей и др. иметь единый id на всех не очень наглядно. однако автоинкремент это настолько простая и естественная вещь, что почему бы её не вынести на уровень таблицы?
    из всех субд, с которыми я работал, отсутствием автоинкрементируемого поля выделилась только “firebird”.

    Рейтинг: 0
  4. в конструкции VARCHAR(n), n и в самом деле количество символов. но при однобайтной кодировке максимальное количество символов 32765, а в случае utf-8 максимально допустимое количество символов — 10921; нельзя задать размер, больший этого значения.
    поэтому (как в математике: 9 пишем, 2 в уме) и здесь также: понимаем, что n — это количество символов, но оно зависит от используемой кодировки. отсюда для простоты можно полагать, что VARCHAR “принимает” максимальный размер в 32 кБ, но чтобы узнать точно значение, надо это разделить на количество байтов, описываемых 1 символом.

    Рейтинг: 0
  5. А насчет php теперь я не знаю, тут вопрос в том, какого типа этот идентификатор в php становится. Это простой integer или класс? (вообще BLOB_ID внутри FB — это INTEGER — ссылка на служебную таблицу с блобами)

    Пример кода на Java, доступ через JDBC — Jaybird:

    ResultSet rs = ps.executeQuery();
    Clob name = rs.getClob(«name»);
    long len = name.length();
    String text = name.getSubString(1, len);

    Я думаю строка максимум в 2^64 байт устроит любого форумчанина.
    Так что проблема в php-библиотеке доступа, но от этого не легчеsad

    Автоинкремент.
    Последняя карта, которая у меня есть, это то, что если пользоваться IBExpert при создании новой таблицы, то там можно галочкой отметить нужное поле как AutoInc, что приведет к автоматизированному созданию Генератора, Триггера и ХП (нужное отмечается галочками, можно отредактировать sql).

    VARCHAR
    Получается что так!
    Только откуда 10921? В UTF-8 от 1 до 4 байт на символ, т.е. сильно зависит от номеров символов в тексте. Среднее или вероятное какое-то?

    Рейтинг: 0
  6. по поводу возвращаемого типа, насколько помню, было большое число (но могу ошибаться!). работа происходит примерно так:
    $db = ibase_connect($database, $user, $password, $charset, 0, 2);
    $sql = ‘SELECT id, comment FROM table’;
    $r = ibase_query($v);
    $n = ibase_fetch_assoc($r);

    теперь в $n содержится ассоциативный массив. если comment — BLOB, то для получения текста необходимо использовать что-то такое (проверить не могу, поэтому беру выдержку из мана):
    $blob_data = ibase_blob_info($n[‘comment’]);
    $blob_hndl = ibase_blob_open($n[‘comment’]);
    $text = ibase_blob_get($blob_hndl, $blob_data[0]);

    в общем-то, это может быть работает гораздо быстрее, но и удобства предоставляет поменьше. классу для работы с firebird это, конечно, без разницы. а вот если этот класс наследуется от другого, «глобального», целью которого стоит унификация хотя бы для 3-4 СУБД, будут проблемы: дабы узнать, какое именно поле в запросе является блобом (ведь его нужно получить дополнительными инструкциями), придётся определить тип каждого из возвращаемых полей.

    в общем-то, мне думается, что в изначальную «архитектуру» можно заложить правило, предписывающее использовать в сообщении не более 10921 символов и не гемороиться, а юзать VARCHAR. а для работы с большими текстовыми данными определить таблицу специальной конструкции.

    по автоинкременту:
    при создании таблицы классом также можно довольно просто определить условное автоинкрементное поле (а триггер обозвать как таблицу). тогда при инсерте всё будет довольно просто, включая и новое значение. ну и опять-таки, дать предписание: при использовании класса первое поле обязательно должно «обзываться» id; соответственно, оно же будет первичным ключём, оно же при вставке будет инкрементится, а как это происходит — определяется уже в классе для конкретной субд.

    VARCHAR
    Вы абсолютно правы: символы в utf-8 могут быть длиной от 1 до 4 байт (теоретически до 6 байт). однако в связи с тем, что 3 символа utf-8 охватывают все значения юникода (U+0000–U+FFFF), в базах для utf-8 полей закладывается использование 3 символов. именно поэтому и используется цифра 3 smile

    Рейтинг: 0
  7. «придётся определить тип каждого из возвращаемых полей.» — если модуль ibase умеет получать метаданные результата запроса (может узнать тип полей), то пара-тройка строк сделают Ваш «глобальный класс» на 3-4 СУБД умеющим работать и с FB. Там всего-то надо написать:

    ResultSet rs = stmt.executeQuery(«SELECT comment FROM table»);
    ResultSetMetaData rsmd = rs.getMetaData();
    String text = null;
    rs.next();
    if(rsmd.getColumnType(1) == java.sql.types.CLOB){
    Clob comment = rs.getClob(«comment»);
    text = comment.getSubString(1, comment.length());
    } else if(rsmd.getColumnType(1) == java.sql.types.VARCHAR /* или любой другой текстовый тип*/){
    text = rs.getString(«comment»);
    }
    return text;

    Ну всё-таки не так много кода, зато + 1 СУБД! Хотя как это будет выглядеть на php с ibase я не знаю.

    Вариант, если ограничить 10921-м символом, то это примерно 4 полных текста страницы А4! Для Twittera пойдет smile Но вдруг на Вашем сайте будут такие юзеры, которые родят продолговатую мысль или будут пытаться описать своё кругосветное путешествие — зависит от концепции сайта, конечно.

    Кстати, всегда было интересно, как пользователи СУБД с автоинкрементным типом сохраняют объекты, которые требуют двух и более таблиц с внешним ключом.
    Например, у меня есть две таблицы
    CLIENT
    ID INTEGER PRIMARY KEY,
    NAME VARCHAR(80)

    PHONES
    CLIENT_ID INTEGER, /*Навешан FOREIGN KEY*/
    PHONE VARCHAR(20)

    В прикладной проге у меня есть класс Клиент, с полями Имя — Строка и Телефоны — Массив строк. И метод save();

    В FB я буду сохранять так:
    1) сделаю запрос к ХП, которая получит новый id клиента из генератора и вернет мне его;
    2) сделаю INSERT в CLIENT
    3) сделаю INSERT’ы телефонов в PHONES, подставив известный мне client_id

    А как вставить, если я, например в MySQL, объвил ID как автоинкрементное ?

    Рейтинг: 0
  8. точно, как и написано выше, классу +/- 3 строки роли не сыграют smile
    почти 11 тысяч символов это много и в большинстве случаев этого вполне хватит (включая чаты, новости, блоги). не хватит этого, например, для некоторых форумов; сообщения там порой бывают очень большие. но на это, по большому счёту, можно подзабить (хочешь написать 20 тыс. знаков — пожалуйста, пиши 2 сообщения). или даже можно “исхитриться”: таблицу создать в 1251, но хранить в ней текст в utf-8, не преобразовывая. да, с поиском будут проблемы, зато для русского текста размер сообщения вырастет ~ до 17000 символов (т. к. пробелы и знаки препинания будут занимать всего 1 символ). но это, кончно, изврат.
    пожалуй, Вы правы. в гугль вио тоже есть ограничение на длину. так что 10000 символов это вполне даже по человечески.

    для mysql и автоинкремента
    FOREIGN KEY как таковой существует только для таблиц InnoDB, которые не пользуются особой популярностью. по сути, данные таблицы используются людьми, с ними знакомыми, или новичками, которые установили софт работающий с данным типом таблиц (но это маловероятно).
    в общем случаем за «внешними ключами» должен следить программист, особо обрабатывая вставки/удаления.
    в чистом mysql автоинкрементное поле после вставки можно получить через LAST_INSERT_ID:
    INSERT INTO table VALUES(NULL, ‘str’);
    SELECT LAST_INSERT_ID();

    функция всегда вернёт корректное значение (даже если произошёл инсерт текущего запроса, а затем другой клиент присоединился и тоже что-то вставил), т. к. LAST_INSERT_ID возвращает последнее добавленного значение для текущего соединения. в зависимости от того, с каким модулем происходит работа. если работа происходит по старинке, то сразу после вставки нужно вызвать функцию mysql_insert_id(). при работе с mysqli ещё проще: значение содержится в свойстве insert_id, помимо которого существуют ещё affected_rows, группа error-свойств (для отслеживания ошибок) и ещё некоторые.
    таким образом, получив корректный идентификатор можно его применять к остальным таблицам.

    // работа через mysqli
    $db = new MySQLi($host, $user, $pass, $name);
    // здесь обработка возможных ошибок
    // в случае успеха имеем экземпляр класса (объект) $db

    $q = ‘INSERT INTO `client` VALUES(NULL, «Иванов Иван Иванович»)’;
    $db->query($q);

    // при успешном запросе значение первичного ключа тут: $db->insert_id
    // теперь можно добавить информацию в таблицу phones
    $q = ‘INSERT INTO `phones` VALUES(‘.$db->insert_id.’, «+7 920 0000000»)’;
    $db->query($q);

    в таблице `phones` значению CLIENT_ID можно объявить первичным или уникальным ключиком, или вообще не объявлять если исключено внешнее вмешательство с нарушением целостности.

    т. е. суть автоинкемент-поля такова: делаем вставку, затем получаем значение добавленной записи. в случаях с генераторами всё наоборот: сперва получаем новое уникальное значение, а потом оперируем им. что называется «на лицо» разный подход.

    Рейтинг: 0
  9. Спасибо за ликбез по MySQL!

    А вот новая информация по Firebird:
    В новой версии FB 3.0 (альфа выйдет в первой половине 2011) вводятся
    identity-столбцы, которые как раз и решают задачу автоинкремента и внешнего ключа для зависимых таблиц.

    create table objects (
    id integer generated by default as identity primary key,
    name varchar(15)
    );

    insert into objects (name) values (‘Table’);
    insert into objects (name) values (‘Book’);
    insert into objects (id, name) values (10, ‘Computer’);

    select * from objects;

    ID NAME
    ============ ===============
    1 Table
    2 Book
    10 Computer

    http://tracker.firebirdsql.org/browse/CORE-1385 — подробная спецификация
    http://www.ibase.ru/conf2010/fb.2010.whatsnew.ru.pdf — доклад с конференции про новые фичи FB
    http://www.firebirdnews.org/?p=4030

    Примера для изящного решения задачи «CLIENT-PHONES» на FB 3.0 с identity пока не нашел.

    Получается, что автоинкремент появится, с блобами разобрались — Firebird ещё машет крыльями smile

    Прочитав доклады с конференции понял, что сложно всё-таки сравнивать эти штуки, даже в Вики пустая страница «сравнение СУБД»! Транзакции, масштабирование, производительность, администрирование, SQL-расширения — много сложных критериев.

    Рейтинг: 0
  10. спасибо Вам за поддержку темы, которая вылилась в такие интересные тенденции smile

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

    то, что Firebird машет крыльями, сомневаться в принципе не приходится. по крайней мере, субд быстрая и не требовательная к системным ресурсам.

    вообще, под термином «сравнение субд» как правило скрывается лукавство. в самом деле, как и что сравнивать? если создать по одной таблички и одним потоком делать вставки, sqlite порвёт всех. но если при этом добавить таблиц, на пару порядков увеличить количество потоков, помимо вставок делать обновления и чтения, sqlite просто захлебнётся (блокировка на всю базу всё-таки не лучшее решение).
    для хорошего тестирования нужен парк аналогичных машин с одинаковой конфигурацией. на одной группе машин будет установленный веб-сервер (у каждой своя субд), на второй группе — один вебсервер и выделенные сервера для каждой субд. и данные гонять не из синтетического теста (20 вставок, 10 записей, поиск, 5 удалений и т. п.), а что-то более-менее реальное. но коль скоро у меня такого парка нет, то и полноценное сравнение провести не представляется возможным.

    кстати, огромное спасибо за ссылочки

    Рейтинг: 0
  11. Чушь какаято насчет автоинкрементного поля и того что идентификатор у всех пользователей (или сообщений форума) будет один. Да, как такового автоинкрементного поля нет, но поверьте, генератор уникальных значений и приделанный на вставку триггер с вызовом генератора (2 стандартные строки, которые генерятся автоматом) работает абсолютно нормально и абсолютно незаметно, так что вы и INSERT можете делать не указав явно ID поля (оно будет вставлено триггером) , а можете и указать ID явно, если хотите, так и select-ы работают без проблем по этому полю.
    Очень жаль что из за такой ерунды вы сразу исключили фаерберд, мне как раз был бы интересен этот обзор.

    Рейтинг: 0
  12. исключил я её не за то, что не смог разобраться в триггерах/генераторах (это уж явно не сложнее, чем хранимые процедуры или курсоры), а из-за группы «проблем» (отсутствие автоинкрементируемого поля; ограничения по максимальной длине текстовых данных; небольшая ценность для конечных пользователей ввиду малого распространения этой субд среди хостеров), создающих элементарные (и не очень) неудобства.
    добавить триггер не проблема; проблема возникает в том, что только что созданное значение нужно получить (причём, если несколько потоков делают вставки, необходимо чтобы каждый поток получил именно свой идентификатор), чего с помощью триггера не добиться. простой пример: пользователь добавляет сообщение и у него в статистике требуется указать id сообщения, оставленного последним. а как мы помним, триггер срабатывает внутри субд до/после наступления указанного события. так что будет просто недостаточно сделать вставку и считать из таблицы последний идентификатор (за это время другой поток вполне успеет заинсёртить ещё одну строку).

    Рейтинг: 0
  13. если Вы готовы помочь, можно написАть нормальный обзор и для FireBird. я ни в коей мере не утверждаю, что субд плоха, просто в рассматриваемом мной контексте она оказалась неудобна, но не более того.

    Рейтинг: 0
  14. Firebird уже давно имеет конструкцию returning для insert`ов и update`ов.
    Эта штука позволяет вернуть значение автоинкрементного поля из запроса без особых сложностей. Но вообще-то firebird лучше всего использовать не просто отправляя запросы, а создав слой бизнес-логики в наборе ХП. И инкапсуляция и безопасность. Давать возможность менять таблицы напрямую не очень здорово. Несомненный плюс такой организации — многие проверки параметров, особенно в части целостности ид можно перенести прямо в базу, не вытаскивая в скрипт. И самое главное — нормальные транзакции! А не то безумие, которое наблюдал в MySQL.

    Рейтинг: 0
  15. serg, вот спасибо за ценное замечание!
    даже удивительно, почему никто больше про это не написал.
    инструкция поддерживается уже с версии 2.0 (только для INSERT) и с версии 2.0.3 (для остального). возвращаются значения, сгенерированные после before-триггеров (но до after, что естественно). можно получить доступ как к старому, так и к уже изменённому значению (актуально для UPDATE`ов, допустим):

    RETURNING OLD.field, NEW.field

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

    тогда на данный момент нерешённым остаётся одна задача: каким образом можно в одном запросе заставить возвратить «много текста» (например, как в случае с форумом: идёт обсуждение темы и кто-то напишет 200 знаков, а кто-то целых 40.000)? или всё-таки издержки на чтение будут минимальными? в php-мане есть такой пример:
    $result = ibase_query(«SELECT blob_value FROM table»);
    $data = ibase_fetch_object($result);
    $blob_data = ibase_blob_info($data->BLOB_VALUE);
    $blob_hndl = ibase_blob_open($data->BLOB_VALUE);
    echo ibase_blob_get($blob_hndl, $blob_data[0]);

    ps: учитывая, что основной и наиболее часто используемой таблицей в mysql является myisam, про транзакции многие даже не задумываются. начиная с версии 5.1 появился новый тип таблиц maria (хотя много где используется mysql 5.0.x), который с версии 5.2 является таблицей по умолчанию. в версии 5.5 умолчательным движком уже является innodb, ранее приобретённый ораклом и запрещённый к использованию в mysql, но после приобретения самого mysql той же корпорацией, вернутым «в зад». в версии 6.0 должна была появиться новая транзакционная таблица falcon, которая бы пришла на замену innodb, но теперь это лишено смысла.
    в некоторых местах mysql выглядит слабее конкурентов (иногда так оно и есть). порой это происходит из-за того, что люди обчитываются информации лохматого года, актуальной для версии 4.x и проецируют её на более новые. однако как бы то ни было, не ошибусь если скажу, что mysql — одна из самых удобных субд. например, в любой момент можно изменить кодировку базы/таблицы/поля без необходимости выполнять редампинг всей базы, после чего спокойно использовать LIKE ‘%text%’ для поиска.

    Рейтинг: 0
  16. Здравствуйте! использую Огненую птицу год, почемуто когда записей в таблице переваливает за 500’000 птица перестает стабильно работать, и при использовании антивируса NOD32 сервер птицы долго включается. Не подскажете если перейти на MySQL от этих проблем можно будет избавиться? И сложен переход на этот MySQL?

    Рейтинг: 0
  17. добрый день
    сложности при переходе, как правило, возникают всегда. основные проблемы — разные типы полей, наследие прошлого (работать с mysql как-будто это огнептиц).
    по конкретному случаю сказать не могу, т. к. птиц должен нормально функционировать и при большем количестве записей (но это зависит от используемых таблиц, правильности составленных индексов, оптимизированности запросов). при использовании стандартных для mysql таблиц myisam несколько раз наблюдал их падение (которое, однако, успешно исправлялось с помощью REPAIR).
    если у Вас не последняя стабильная версия, попробуйте обновиться (либо даже переустановить операционную систему, т. к. проблемы, порой, бывают не там, где думается).
    на одной из конференций была тема, посвящённая новой версии постгреса. так сказано было буквально следующее: мы обновились, а на следующий день полезли смотреть логи по нагрузки и были ошарашены; мы думали, нас взломали. нагрузка упала в несколько раз.

    Рейтинг: 0
  18. А представьте, если бы Ваш блог был бы повыше в рейтинге Яндекса, очень много бы людей прочли этот пост.

    Рейтинг: 0
  19. Админ, а можно я размещу этот пост на своём сайте?

    Рейтинг: 0
  20. Занятно! Реально просто отлично написано. smile

    Рейтинг: 0
  21. Ну про триггер и генератор в FireBird совсем не стоило писать и тем более отсеивать из за этой мелочи, в Oracle например, значение PK генерируется по такому же принципу, создается последовательность(генератор) и триггером генерируется следующее значение, не скажете же Вы из за этого, что Oracle плохая СУБД.

    Рейтинг: 0

Оставить комментарий

Политика конфиденциальности

Наш сайт использует файлы cookies, чтобы улучшить работу и повысить эффективность сайта. Продолжая работу с сайтом, вы соглашаетесь с использованием нами cookies и политикой конфиденциальности.

Принять