» Продолжение Вопроса о выборе БД... :)

Предыдущий вопрос был следующим :
Подскажите какую локальную БД лучше с точки зрения надёжности,
скорости работы И безопасности выбрать? С ней будут работать 2-3
(максимум 5 пользователей). Общее кол-во записей во всех таблицах 10-15 тыс.
Максимум 50.Клиентское приложение будет на Delphi 7.0.

Итак: Большое СПАСИБО всем учавствующим. Но я наверное забыл добавить БД будет находиться на локальной машине (расшарен каталог , для других юзеров) и я бы не очень хотел запускать каких-нибудь обработчиков запросов СУБД, интенсивность запросов при 2-х юзеров , кот. будут ручквми всё заносить естественно небольшая И хотелось бы поменьше всякой ерунды ставить (даже тотже BDE).

И я думаю никаких триггеров и хранимых процедур ест-но не нужно в данном случае (во всяком случае я бы вопрос по другому поставил (какую Серв-ю Субд посоветуете))

Поэтому : 1. MySQL - нужен запущенный обработчик запросов, и интересно как бы я с Delphey с MySQL работал (я вот что-то вот совсем отстал (да, работал с MySQL на PHP - олично, но Delphi + MySQL -что то новое или я чего-то не знаю - подскажите тогда)).

2. MS SQL Server , Oracle и прочее серверные СУБД естественно отпадают - (10-15 таблиц - 2 юзера) - смешно просто, я уже про это чуть выше писал. Также Interbase - тежеловат наверное + наверное обработчик + не работал-не знаю.

3. Jet 4.0 меня заинтересовала и MSDE. И вообще я думал спор будет Paradox (всё-таки Delphi ) или Acccess, но слышал что Access по надёжнее.

И теперь меня интересует => 1. Итак на сколько эффективно/надёжно/неглючно и т.д. ADO - компоненты делфи работают с Access , тем же Jet 4.0 (BDE ведь не нужно будет устанавливать).
2. Что Вы скажете о Paradox.
3. Что нужно для работы с MSDE?
4. И может кто подскажет как быстро склепать приложение на Delphi для работы с MySQL (способ про установку ODBC - драйвера MySQL, кот потом в BDE виден и через эти 2 прослойки работать с MySQl даже слышать не хочу - криво).

Спасибо.

Negr

Цитата:

MS SQL Server , Oracle и прочее серверные СУБД естественно отпадают - (10-15 таблиц - 2 юзера) - смешно просто, я уже про это чуть выше писал. Также Interbase - тежеловат наверное + наверное обработчик + не работал-не знаю

Цитата:

Jet 4.0 меня заинтересовала и MSDE

Смешались в кучу кони, люди...
1. MSDE - та же серверная СУБД, что и MSSQL (ядро у них общее), только с несколько урезанной функциональностью. Так что...
2. Interbase/Firebird так же является серверной СУБД правда куда более легкой, чем MSSQL/MSDE
3. Между Paradox и Access я бы выбрал Access

Цитата:

Итак на сколько эффективно/надёжно/неглючно и т.д. ADO - компоненты делфи работают с Access , тем же Jet 4.0 (BDE ведь не нужно будет устанавливать)

Я не в курсе про работу из Delphi (использую VC++ 6), однако должен сказать, что ODBC по заявлениям Microsoft является native API для MSSQL/MSDE/Access, а по сему работая через ADO поверх ODBC получишь максимальную производительность по сравнению с другими API (я не говорю про производительность самой СУБД, т.к. она мало связана с API клиентских приложений).

Цитата:

И может кто подскажет как быстро склепать приложение на Delphi для работы с MySQL (способ про установку ODBC - драйвера MySQL, кот потом в BDE виден и через эти 2 прослойки работать с MySQl даже слышать не хочу - криво).

Скажем так, для разработки GUI приложений ориентированных на работу с базами данных BDE неплоха, но не более. Кривая она по своей сути
Работай напрямую с MySQL через ODBC и ты получишь нормальное быстродействие.
С MySQL есть еще один вариает работы - embedded. Это когда сервер СУБД является частью твоего приложения и ты компилишь свою прогу с частью исходников СУБД. Правда подходит он только для C/C++

Добавлено
Если же лень слазить с BDE, то используй Paradox и не морочь себе голову

Negr
Честно говоря, не понимаю чем не устраивает MySQL. Компоненты для Дельфи есть. Что еще надо? TMySQL, например, не использует ни BDE, ни ODBC, к тому же OpenSource . Если все же не подходит, поищи здесь: http://www.mysql.com/portal/software/api/index.html

Не понимаю смысла фразы:

Цитата:

нужен запущенный обработчик запросов

Оно же занимает совсем чепуху, зато не тормозит!

С Access я однажды работал (приложение было на Visual Basic). Ох и много же я тогда неприличных слов произнес. Впечатления ужасные. Врагу не пожелаю...

Насчет Paradox - масштабируемость отсутствует (в случае с Access, кстати, тоже). А MySQL же масштабируется превосходно.

Если не ошибаюсь в первом посте присутствовала фраза о защите данных. Если имеется в виду разделение доступа к данным - всяко нужен какой-нибудь SQL-сервер. IMHO в Access нет этой фичи.

Mickey_from_nsk

В Access есть встроенная система безопасности, причем весьма разветвленная (пользователи/группы, права разных типов для всех типов объектов (таблицы/формы/отчеты...) и т.д.).

Только вот, насколько это все защищенно при наличии физического доступа к файлу БД на шаре (в том числе и с правами на запись)? Инструменты для снятия защиты с Офисных продуктов есть в Сети в немалом количестве.

Под защищенностью в данном случае я подразумеваю невозможность выполнить пользователем заданную операцию без соответствующих прав, даже если у него есть права на другие операции. Например, скопировать базу локально, поработать с ней спец-средствами, внести напрямую нужные ему данные и записать обратно. Администратор, при желании, может ему сильно затруднить жизнь, но принципиально исключить такую возможность с shared-file-DB не получится.

Negr
Перед тем, как делать окончательный выбор, выясни для себя требуемый уровень безопасности. Если есть 5 пользователей с равными правами и задача системы безопасности сводится к тому, что бы разделить весь мир на имеющих и не имеющих прав доступа к системе, то acess/paradox/etc. по критериям безопасности может подойти. О других критериях я сейчас не говорю.

Если данные "чувствительны" к защите и права у всех пользователей разные, то лучше остановиться на серверной СУБД. Пускай и простой, но серверной. Это может быть mySQL, MSDE (его бесплатность намного шире, чем писали в предыдущих постах. Об ней можно прочитать здесь). Сам выбор не принципиален, лиш бы тебе было удобно этим продуктом пользоваться.

Кроме того, попробуй спрогнозировать дальнейшее развитие твоей разработки. Если предполагается рост пользователей и данных, выпуск новых версий, то это еще один довод в сторону серверной БД. Если же это первая и последняя версия, количество пользователей расти не будет - см. выше.

Господа!
Ну посмотрите на исходные данные:
5 юзеров и 10 тыс записей!
Ну это же курам на смех!

Мне кажется выбор только из двух:
Access и MySQL.

Вот и выбирай: или серверная MySQL, но надо ее устанавливать,
что может иметь потенциальный геморрой при дистрибуции
(типа если ты пишешь инсталляшку и может начаться: ой у меня MySQL
не проинсталлировался - что делать);
или файловая Access - вроде проблем меньше, хотя на Win 95
надо апдейтить Jet.

Тем более если ты начинающий негр (сорри), то проще начать с Access.


Добавлено
PS: И забудь про Paradox !!!!!
PPS: И BDE.

Цитата:

PS: И забудь про Paradox !!!!!
PPS: И BDE.

А чем так BDE и PARADOX Вам не взлюбился?

Pupsik

Цитата:

Господа!
Ну посмотрите на исходные данные:
5 юзеров и 10 тыс записей!
Ну это же курам на смех!

ценность информации и требования к ПО (платформе) для ее обработки, в общем случае, не зависят от количества пользователей и записей. Если цена одной строки в таблице измеряется в килобаксах, пользователями являются топ-руководители, а раскрытие (утечка) информации может привести к банкротству - то количественные показатели перестают быть определяющими.

В первом посте темы было упоминание о наличие требований к безопасности (правда без детализации). Возможно, для данного случая, вопросы безопасности не являются критичными, но и совсем забывать о них тоже не стоит. Как и пробовать сделать выбор платформы без учета требований к системе в целом. Можно сильно промахнуться, если брать в расчет только N users/rows/GBs/etc. Система то создается для решения бизнес-задач, а не для хранения записей.

Negr

Насколько критична планируемая система с точки зрения надежности и безопасности обрабатываемых данных?

Какие факторы для тебя являются ключевыми? Только количественные показатели (пользователи/строки) + работа БД с Delphi или есть и другие? Если да, то какие?

mymuss

Цитата:

Честно говоря, не понимаю чем не устраивает MySQL

Цитата:

к тому же OpenSource

Не устраивает скорее всего из-за того, что к открытому коду на Win платформе в отличии от Linux не прилагается свободное коммерческое использование. За MySQL на Win надо платить деньги и не малые - за один сервер порядка $100.

Тут уж дешевле выдрать из MS Office 2000/XP инсталляшку MSDE и пользоваться им, т.к. все равно на 99% компьютеров пользователей и так стоит офис, а лицензионный он или нет - это уже не твоя проблема, т.к. твой софт его лишь использует. Вот... В случае с MySQL та же петрушка за один маленьким "но" - у заказчика есть довольно большая вероятность наличия таки лицензии на офис (особенно в нашей с тобой родной самостийной Украине, где уж не первый год гоняют за пиратские копии продуктов Microsoft).

Итог: если сервер на Win, то ориентироваться на MSDE или Access, иначе - MySQL.
Только у Negr в обоих случаях будут "косяки" с Delphi, т.к. использовать BDE не есть хорошо, а насколько прямо напрямую (сорри за тавтологию ) вызываются различные Win API оттуда мне не известно (еще один кирпич в сторону Delphi, но это совсем другая история)

Цитата:

но Delphi + MySQL -что то новое или я чего-то не знаю - подскажите тогда

Проще всего - последняя версия MySQL + ODBC драйвер, все есть на оффсайте.

v0yager

Цитата:

ценность информации и требования к ПО (платформе) для ее обработки, в общем случае, не зависят от количества пользователей и записей. Если цена одной строки в таблице измеряется в килобаксах, пользователями являются топ-руководители, а раскрытие (утечка) информации может привести к банкротству - то количественные показатели перестают быть определяющими.

И поэтому мы ставим программу на клиентский компьютер и расшариваем файлы для всех (или почти всех). Не смешите. Если такие жетские требования к безопастности никто не заикнется о расшаривании БД и установке сервера на клиенте.

Negr

Цитата:

и я бы не очень хотел запускать каких-нибудь обработчиков запросов СУБД,

Любая СУБД требует клинета. И сама СУБД является обработчиком запросов.

Цитата:

Также Interbase - тежеловат наверное + наверное обработчик + не работал-не знаю.

Влазит на одну дискету. Работает под Win95, может работать даже на 486. Есть сообщество русско-говорящих разработчиков (ib.demo.ru), есть компоненты прямого доступа, как стандартные, так и сторонние. Клинет занимает мало места. Бесплатен (FireBird). Есть персональный сервер (Yaffil Personal) который бесплатен и размещается в одной DLL. Может работать как под Win так и под другими платформами.

SerVlad

Цитата:

ценность информации и требования к ПО (платформе) для ее обработки, в общем случае, не зависят от количества пользователей и записей

Цитата:

И поэтому мы ставим программу на клиентский компьютер и расшариваем файлы для всех (или почти всех). Не смешите. Если такие жетские требования к безопастности никто не заикнется о расшаривании БД и установке сервера на клиенте.

Никакого смеха. Абзац, который ты процитировал, я привел в качестве комментария для одного из предыдущих постов. В этом ответе описан случай, когда платформу для БД нельзя выбирать на основании ТОЛЬКО количественных оценок строк / пользователей.

Меня, как и тебя, смущает противоречие: в условиях задачи умоминаются требования к безопасности и одновременно рассматривается возможность работы с file-shared-DB.

Комментарий по этому поводу я уже писал:


Цитата:

Только вот, насколько это все защищенно при наличии физического доступа к файлу БД на шаре (в том числе и с правами на запись)? Инструменты для снятия защиты с Офисных продуктов есть в Сети в немалом количестве.

Под защищенностью в данном случае я подразумеваю невозможность выполнить пользователем заданную операцию без соответствующих прав, даже если у него есть права на другие операции. Например, скопировать базу локально, поработать с ней спец-средствами, внести напрямую нужные ему данные и записать обратно. Администратор, при желании, может ему сильно затруднить жизнь, но принципиально исключить такую возможность с shared-file-DB не получится.

Так что оценки защищенности file-shared-DBs у нас похожи

P.S. SerVlad - с первым постом на ру-борде! Удачи.

Bloody_Nokia_Adept

Цитата:

Это когда сервер СУБД является частью твоего приложения и ты компилишь свою прогу с частью исходников СУБД

......только не с исходниками, а с библиотекой libmyqld

Господа, о чем спор, о какой безопасности и т.п., прочитайте еще раз внимательно исходные требования:

Цитата:

во всяком случае я бы вопрос по другому поставил (какую Серв-ю Субд посоветуете))

Цитата:

БД будет находиться на локальной машине (расшарен каталог , для других юзеров)

!!!!!
Не хочет человек серверную СУБД, не хочет. О чем спор?

Pupsik

Прочитал. исходные требования:

Цитата:

Подскажите какую локальную БД лучше с точки зрения надёжности,
скорости работы И безопасности выбрать?

в тоже время сказано и:

Цитата:

Но я наверное забыл добавить БД будет находиться на локальной машине (расшарен каталог , для других юзеров)

Сложность сочетания надежности, скорости и безопасности с file-shared-DB как раз и вызвали сильные сомнения.

Цитата:

Не хочет человек серверную СУБД, не хочет. О чем спор?

Если действительно не хочет - то причин для дискуссии нет. Как и причин утверждать, что конечное решение будет надежным и безопасным. Тогда нужно корректировать исходные требования...
Negr
Так что же для тебя все-таки важнее?

Negr

Цитата:

1. Итак на сколько эффективно/надёжно/неглючно и т.д. ADO - компоненты делфи работают с Access , тем же Jet 4.0 (BDE ведь не нужно будет устанавливать).

Правильно!
Цитата:

И может кто подскажет как быстро склепать приложение на Delphi для работы с MySQL (способ про установку ODBC - драйвера MySQL, кот потом в BDE виден и через эти 2 прослойки работать с MySQl даже слышать не хочу - криво).

Ну что ты прицепился к этому БДЕ !!! Им уже года 3 никто не пользуется!
Для мускуля есть ОЛЕ драйвер - зовется myOLEDBProvider! (под АДО чтоб юзать) Скачать можно с сайта самого мускуля (там в довнлоадсе ссылка есть)!

Успехов - если че : mamay@ziet.zhitomir.ua или в ПМ!

Pupsik

Цитата:

Не хочет человек серверную СУБД, не хочет. О чем спор?

Понимаешь, я тоже свое первое приложение написал на Парадоксе, а когда через несколько лет его пришлось переписывать на клиент/сервер, то очень долго плевался. А начиналось точно также. Пара пользователей, файловая шара, небольшой объем. И дорос до 15 пользователей и ~170 Мб данных. Вот и стараюсь уберечь человека от наступления на грабли. Сейчас если идет речь о возможной работе в сети, то я уже закладываю сервер БД. Благо он весит не много (Interbase, вернее его клоны).

И требования к безопасности примерно совпадают. Нужно обеспечить разделение данных по пользователям, целостность данных. А так если нужна информация из этого приложения "купят" оператора или начальника. Это гораздо дешевле чем мучаться со взломом

vserd

Цитата:

а когда через несколько лет его пришлось переписывать на клиент/сервер, то очень долго плевался

Ну и в чем проблема? Не используй BDE и все.
Пиши на ADO, если сменишь СУБД - измени строку подключения в tADOConnection и вперед в сеть...
Утрирую, конечно.

Firebird (open-source развитие Interbase) бесплатный, например... Сервер легкий, клиент комплектуется одной dll без специальной установки.

File-shared DB, для описываемых условий, лучше не применять.

Цитата:

Для мускуля есть ОЛЕ драйвер - зовется myOLEDBProvider!

TADODataset юзать как компоненты?

Какой на фиг Access. У тебя база будет весить немеренно. Больше чем дистрибулив Oracle. У меня в Access база из одной таблицы строк на 5000. Так эта штука весит 80 метром. Хотя текстовыйфайл, из которого загружал, весил килобайты. Вот такая штука. Так что я думаю MySQL и никаких гвоздей.

Цитата:

У меня в Access база из одной таблицы строк на 5000

Совершенно ни о чем не говорит. У меня база из 6000 строк и 20 таблиц весит 15 метров.
Может ты давно не делал:
Сервис / Служебные программы / Сжать и восстановить базу данных ?
Access имеет свойство в некоторых случаях пухнуть...

Хотя против MySQL ничего не имею...

Да точно сжалась. Интересный факт. Что он там историю хранит что ли?

Цитата:

Да точно сжалась. Интересный факт. Что он там историю хранит что ли?

А хранит он все ваши удалённые коды VBA, кот. он помечает как удалённые, но физ-ки их не удаляет!!

Да не в удалеии дело. Это база используется для накопления информации.Чиселки туда с приборчиков загоняюся. И все. Ну так вот очень быстро она пухнет.

UncoNNecteD

Цитата:

TADODataset юзать как компоненты?

Это ты к чему???

Pupsik

Цитата:

а когда через несколько лет его пришлось переписывать на клиент/сервер, то очень долго плевался
Ну и в чем проблема? Не используй BDE и все.
Пиши на ADO, если сменишь СУБД - измени строку подключения в

Гдеж ты был такой умный когда я первое приложение писал? :))
Ненавижу OLE никакой уверенности в приложении. То работает, то нет. Лучше я на прямом доступе посижу.

Цитата:

Гдеж ты был такой умный когда я первое приложение писал? )

Это наезд?

Цитата:

Ненавижу OLE никакой уверенности в приложении. То работает, то нет.

Странно. Проблем с ADO не было никогда. Где там что не так?

Pupsik

Цитата:

Это наезд?

Нет. Извиняюсь если прозвучало именно так. :(
Просто констатация факта что тогда было первое приложение на Delphi. И как оказалось переход локальная БД--> Клиент/сервер не такой уж и простой. Хотя расписывалось как именно замена алиаса.

Цитата:

Ненавижу OLE никакой уверенности в приложении. То работает, то нет.
Странно. Проблем с ADO не было никогда. Где там что не так?

Тот факт что это работает через OLE достаточен для не использования. Исходя именно из негативного опыта работы с OLE. И именно для меня.

vserd

Цитата:

Delphi

Цитата:

Тот факт что это работает через OLE достаточен для не использования. Исходя именно из негативного опыта работы с OLE. И именно для меня.

Два ключевых слова - Delphi и OLE. Из VC++ 6/.Net все нормально работает. Грабли видимо не в OLE или ADO, а в bridge между Delphi и ними. Так что...

А ADO сам по себе - нормальный интерфейс.