Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

MS SQL или MySQL [D7, Paradox]

Страницы: < 1 2 3 >
beglec © (2006-04-08 13:28:00)
Возникает потребность к переходу на SQL платформу.
В сами программы не нужно переделывать - они уже и так все пользуются SQL запросами. Но через одну мою процедуру. Моя процеДурка использует пока локальные базы Paradox.
Данные растут запросы тоже. Но пока все хорошо работает, причем довольно шустро, база не лопается - хотя уже и 400 тыс. записей - даже индексы не слетают. (Это я к тому, что здесь бывает часто жалуются, что Paradox это есть не хорошо) фигня - главное голова и руки.
Ну так вот - планируются существенные изменения и очень большое увеличение данных. По прикидкам, анализам и предварительным тестам - Paradox справится. Но затраты на создание такой вещи - существенно больше, нежели если этот проект делать на прямую с SQL сервером. Еще вскрылся один недостаток у Paradox это то, что он плохо работает с WWW (php). Мало кто его поддерживает. А интернет дело такое.

Так вот, пока не поздно надо делать выбор, но какой?
Подскажите пожалуйста
1. Ссылку, где доходчиво написано разница между MS SQL и MySQL? (после просмотра популярных статей (через поисковик) в internet на эту тему понял, что пишется везде одно и тоже и одна вата – размытость, ничего конкретного. Видимо друг у друга переписывают. Многое что написано неправда – проверено.
2. Напишите, кто уже писал программы на Delphi под эти сервера – есть ли какие нибудь подводные камни – что бы их можно было сразу учесть при проектировании.
3. Какие компоненты можно использовать для работы с БД (кроме ADO) и в чем их преимущество?

В данный момент у меня уже стоит и MS SQL и MySQL
Выяснил следующее:
MS SQL - работает хорошо с Delphi, имеет быстрый коннект, это плюс
MySQL не совсем корректно работает с Delphi (нет компонентов), это минус
MySQL много платформенный, это плюс.
MS SQL имеет отличный анализатор и сбор статистики - это большой плюс

P.S. А еще меня вопрос все время мучает. А что конкретно то передает SQL сервер клиенту по сетке. Что именно передает SQL по сетке? Сжимает ли он их для более быстрой передачи? Где и как можно посмотреть трафик SQL сервера? Сколько байт, записей, передано? Было бы не плохо и про это почитать.

P.S.S. InterBase и Informix отпали – потому как умерли при создании в цикле 1 000 000 записей более чем на 4 часа. MSSQL и MySQL справились с этой задачей за 20 минут. Поэтому выбор остановился на них.

P.S.S. Еще есть выбор DB2, но по этому продукту у меня совсем мало русскоязычной информации, хотя и хвалят его очень и очень положительно и по скорости и по мобильности.

Спасибо.
Извините за большую писанину, просто хотел более четко изложить суть своей проблемы.

Курдль (2006-04-10 16:31:00) [21]

> beglec © (10.04.06 15:53) [18]
> Идеальных вещенй не бывает.

Кстати. Идеальных вещей не бывает. Идеальные СУБД - да.
Это oracle. Причем забавно, что Вы прошлись по всему спектру, от Парадокса до DB2, а про оракл - ни слова :)

beglec (2006-04-10 16:25:00) [22]
Нет вопросов больше нет.
сижу вот только взвешиваю все за и против.
Считаю что прочитал достаточно для предварительного выбора.

Курдль (2006-04-10 15:59:00) [23]

> Есть большая потребность в "Ключах" потому как текущая модель
> практически вся построена на них. Кто как с ними работает :)))

Вообще, конечно, топик загадоШный, как и автор.
Что значит "потребность в ключах"? Имеются в виду первичные и внешние ключи? Модель реляционной базы всегда бывает построена на них. А как иначе?
А последнее предложение - это шЮтка, или вопрос?
Если вопрос, то все работают с ними до скучного однообразно, если для проектирования базы используют CASE инструменты. Последние не дадут про них забыть или использовать не по назначению.

Sergey13 (2006-04-10 15:58:00) [24]
>Есть большая потребность в "Ключах"
В смысле?

beglec (2006-04-10 15:53:00) [25]

> Кстати, а она научилась работать с транзакциями, серверной
> логикой и т.п.?

пишут что с 5.0 научился

> Sergey13 © (10.04.06 14:33) [15]

хорошо поразбираюсь - интересное замечание - спасибо

> Я же говорю, вы не умеете его готовить.

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

Как говориться в спорах рождается истина.

в сторону MySQL смотрит также тот факт, что есть 2 программера пишушие на PHP и работаеют с MySQL - но пока пишут всякие мелкие справочники.
Если остаться на MySQL - то переделка их справочников займет мало времени. Но вот в будущем если SQL сервер будет выбран не верный то переделка этих маленьких справочников будет цветочками.
Соглашусь с тем, что каждый SQL сервер где то хорош а где имеет погрехи. Идеальных вещенй не бывает.
Например пока особо "SQL функции" не нужны. Но это может оказаться обманчивым - ведь я пока не знаю всю прелесть данного инструмента.
Есть большая потребность в "Ключах" потому как текущая модель практически вся построена на них. Кто как с ними работает :)))

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

Курдль (2006-04-10 15:34:00) [26]

> После ночных поисков пока больше плюсов в сторону MySQL.

Кстати, а она научилась работать с транзакциями, серверной логикой и т.п.?

atruhin (2006-04-10 15:24:00) [27]

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

Я же говорю, вы не умеете его готовить.

> [15] Sergey13 © (10.04.06 14:33)
> В случае с FB на ХР, если файл базы имеет расширение GDB,
> то нарываются на (кажется)

Именно так хуже то, что при таком варианте в случае сбоя XP база вылетает на дату воостановления :)

> проверял не только я, но и знающие люди которые работали
> с этим базами.

Приведи скрипт таблицы на которой вставка 1000000 записей занимает у тебя больше 4 часов. Посмотрим.

Sergey13 (2006-04-10 14:33:00) [28]
2[14] beglec © (10.04.06 14:23)
Например, иногда, некоторые программисты во время коннекта открывают все датасеты (а некоторые могут запрашивать все записи из нехилых таблиц), и потом удивляются, что "коннект долгий". В случае с FB на ХР, если файл базы имеет расширение GDB, то нарываются на (кажется) резервное сохранение файла. Там это расширение зарезервировано. Разные, вобщем, бывают причины "долгого коннекта".

beglec (2006-04-10 14:23:00) [29]

> Ты пишешь программу по установлению коннекта? 8-)

Да нет :)))
просто клиенты ругаются когда долго коннект идет, не важно где :)

Многие ведь ругаются когда модем долго соединяется или Windows долго грузится :))) вот и долгий коннект с базой тоже выводит из себя народец. Нервный у нас народец нынче :) - поэтому и является данный факт (факт долгого коннекта) важным фактом при выборе ПО СУБД.

sniknik (2006-04-10 12:42:00) [30]
> Ну да, и клиента ставить не надо?
в общем случае нет, он входит в MDAC. поставить ADO без клиента MSSQL это надо еще постараться... и еще не факт, что получится.

Плохиш (2006-04-10 12:32:00) [31]

> beglec © (10.04.06 11:45) [10]
> Разобрался со многими вещами уже.
> например ADO имеет по умолчанию способо соединения с MSSQL

Ну да, и клиента ставить не надо?

Sergey13 (2006-04-10 11:48:00) [32]
2[10] beglec © (10.04.06 11:45)
Ты пишешь программу по установлению коннекта? 8-)

beglec (2006-04-10 11:45:00) [33]

> Плохиш

Разобрался со многими вещами уже.
например ADO имеет по умолчанию способо соединения с MSSQL
а что бы это дело заработало с MySQL - то нужно дополнительно скачивать приблуку с сайта ADO. Скачал ужо все робит.

MS SQL - идентификация пользователя проходит довольно быстро - быстрее всех по времени.
Потом идет по времени MySQL
самый долгий InterBase - пока не разобрался почему. Но идентификация пользователя доходит до 5 минут.

Плохиш (2006-04-10 11:40:00) [34]

> MS SQL - работает хорошо с Delphi, имеет быстрый коннект,
> это плюс
> MySQL не совсем корректно работает с Delphi ( нет компонентов),
> это минус

Хотелось бы услышить, какие это есть специальные компоненты для работы с MSSQL?

Sergey13 (2006-04-10 11:15:00) [35]
Даже при формальной переносимости запроса, он бывает неработоспособен по сути. Например Select max(id) form table для получения ИД новой записи будет вполне работоспособен везде, однако пользоваться им в многопользовательской среде - мягко говоря неправильно.

Anatoly Podgoretsky (2006-04-10 11:11:00) [36]
beglec © (10.04.06 10:35) [5]
Только сверх простые запросы можно переносить без переделки

sniknik (2006-04-10 11:00:00) [37]
> Изначально все программы проектировались таким образом, чтобы можно было переходить на другую SQL платформу без болезненно и без
> переделки запросов. И это мне удалось!
т.е. переводя на понятный язык, используются только те контрукции, которые поддерживаются всеми sql серверами?
тогда в выигрыше будет самый простой с неразвитой функциональностью сервер. (ну к примеру простая выборка select, на сервере поддерживающем/неподдерживающим тригеры будет (в идеале, не учитывая других факторов) выполнятся быстрее на неподдерживаемом... т.к. на те же проверки есть тригер/нет тоже время нужно). и т.д. любая возможность/особенность, которая при использавании дает преимущества/скорость, при неиспользовании будет недостатком/тормозом (при сравнении с системой этой особенности не имеющей).

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

> P.S. Да! цена - тоже фактор.
0 vs 0 (если не гнаться за промышленными маштабами)

beglec (2006-04-10 10:35:00) [38]

> Anatoly Podgoretsky

Изначально все программы проектировались таким образом, чтобы можно было переходить на другую SQL платформу без болезненно и без переделки запросов. И это мне удалось!

> Nikolay M. ©
> А в результате - много воды о непонятных критериях "лучшести"
> (какой-то "быстрый коннект", "нет компонент для MySQL" -
> если ты их не нашел, это не значит, что их нет и тд).

я написал то что уже успел найти и попытался сократить время поиска - разместив свой вопрос сюда.

> atruhin © (09.04.06 07:21) [3]
> А может вы просто не умеете его готовить?

проверял не только я, но и знающие люди которые работали с этим базами.

После ночных поисков пока больше плюсов в сторону MySQL.

P.S. Да! цена - тоже фактор.

YurikGL (2006-04-09 15:20:00) [39]

> MySQL не совсем корректно работает с Delphi (нет компонентов),
> это минус

dbExpress

atruhin (2006-04-09 07:21:00) [40]

> InterBase и Informix отпали – потому как умерли при создании
> в цикле 1 000 000 записей более чем на 4 часа.

А может вы просто не умеете его готовить?

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »