Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Выбор субд

26K
07 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
Какую базу данных лучше выбрать для приложения, с возможностью одновременной работы до 100 пользователей, без установки субд (сервера) на компьютер?

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

Слышал, что Access поддерживает до 50 одновременных подключений. Не понимаю, как это? Раз база работает и без сервера. Объясните!
11
07 августа 2008 года
oxotnik333
2.9K / / 03.08.2007
Выбор СУБД это настолько интимный вопрос, что вряд ли кто раскроет свои секреты... скорей всего пошлют в поиск.
8.2K
07 августа 2008 года
Ora-cool
211 / / 20.09.2007
Что-то не понял. Вы хотите выбрать СУБД (сервер управления БД) без установки сервера? Это как?
Для выбора СУБД нужно проанализировать множество критериев - назначение БД (список решаемых задач), режимы работы, требования к надежности и отказоустойчивости, стоимость/бесплатность СУБД, сложности администрирования и т.д. и т.п.
26K
07 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
У меня есть приложение, оно должно сохранять данные. Соответственно нужно выбрать бд. Access уникальна тем, что приложение работает с фалом базы (*.mdb) без установленной Access. То есть, я так понял, субд Access сервером назвать нельзя. Но тут ограничение в 50 чел
1.9K
07 августа 2008 года
max_dark
256 / / 11.11.2005
Посморите SQLite
Встраивается в приложение как модуль
Так что Access не уникален :)
26K
07 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
Спасибо, вроде подходит
5
07 августа 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: vitaliy_lyakh
Спасибо, вроде подходит


Аналогично предложу SqlServerCompact (Тот что раньше был мобайлом).

341
07 августа 2008 года
Der Meister
874 / / 21.12.2007
А если не использовать архитектуру клиент-сервер, то какой смысл вообще использовать СУБД? Типизированные файлы проще и работают быстрее...
8.2K
07 августа 2008 года
Ora-cool
211 / / 20.09.2007
Я вот никак не пойму насчет требования одновременной работы 100 пользователей и при этом речь идет о настольной СУБД...
341
07 августа 2008 года
Der Meister
874 / / 21.12.2007
Цитата: Ora-cool
Я вот никак не пойму насчет требования одновременной работы 100 пользователей и при этом речь идет о настольной СУБД...


А если она вовсе и не настольная, то можно просто заключить всю бизнес-логику в нормальную СУБД (используя, к примеру, CLR хранимые поцедуры MS SQL Server) и получить единое серверное приложение. Устанавливать придётся только его.

26K
08 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
Цитата: Der Meister
А если не использовать архитектуру клиент-сервер, то какой смысл вообще использовать СУБД? Типизированные файлы проще и работают быстрее...



А разве удобнее будет использовать простые файлы, чем бд, пусть даже жертвуя скоростью?

26K
08 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
Цитата: Der Meister
А если она вовсе и не настольная, то можно просто заключить всю бизнес-логику в нормальную СУБД (используя, к примеру, CLR хранимые поцедуры MS SQL Server) и получить единое серверное приложение. Устанавливать придётся только его.



Можете об этом поподробнее? Не совсем понял, как это избавит от установки сервера бд?

26K
08 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
Цитата: hardcase
Аналогично предложу SqlServerCompact (Тот что раньше был мобайлом).



http://ru.wikipedia.org/wiki/SQL_Server_Compact_Edition

"SQL CE не оптимизированна для большого количества одновременных пользователей"

"Многопользовательская работа с одним файлом базы данных с разных компьютеров — не поддерживается в связи с техническими сложностями"

26K
08 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
Думаю, буду использовать SQLite, или, может быть, Access - всё-таки 50 одновременных это немало. Кстати, файл в формате accdb (Access 2007) намного больше чем mdb. Есть ли смысл использовать новый формат?
1.9K
08 августа 2008 года
max_dark
256 / / 11.11.2005
При использовании Access прийдется ставить драйвер соответсвующей версии(если Access этой версии не установлен на данном компьтере), в то время как в SQLite "все включено"
26K
08 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
Цитата: max_dark
При использовании Access прийдется ставить драйвер соответсвующей версии(если Access этой версии не установлен на данном компьтере), в то время как в SQLite "все включено"



А разве драйвер для Access (2000-2003) не устанавливается вместе с NET Framework?

1.9K
08 августа 2008 года
max_dark
256 / / 11.11.2005
Во первых, Вы не указывали, что пишите используя .NET
Во вторых, я не знаю, так как я НЕ использую .NET и пишу в основном на чистом С

Если так, как вы говорите, то вам лучше использовать Access, так как для SQLite вам прийдется писать/искать врапер под данную платформу
26K
08 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
max_dark, сасибо за советы. У вас случайно нет опыта использования access 2007? есть ли в нём смысл?
1.9K
09 августа 2008 года
max_dark
256 / / 11.11.2005
С Access 2k7 дела не имел. И не собираюсь )
Использовать ли его или нет - решать только вам.
Попробуйте и сравните разные варианты.
Если же поджимает время, ИМХО, лучше использовать то, с чем приходилось работать
5
09 августа 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: vitaliy_lyakh
http://ru.wikipedia.org/wiki/SQL_Server_Compact_Edition

"SQL CE не оптимизированна для большого количества одновременных пользователей"

"Многопользовательская работа с одним файлом базы данных с разных компьютеров — не поддерживается в связи с техническими сложностями"

Многопользовательский доступ к БД реализуется на уровне процесса-хоста, в котором работает движок БД.

Если у вас такая уйма клиентов (порядка сотни), то может быть имеет смысл исползовать нормальную СУБД типа Sql Server 2005? Можно даже и бесплатную версию - ее вам точно хватит.


З.Ы. А аксесс у вас загнется нахрен :))

26K
10 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
hardcase, всё таки Access уникален, если писать под .NET. Но если вы говорите, что он загнётся, то, может, действительно отказаться от такой идеи? Впринципе, если не будет глюков при большом количестве одновременных доступов, а просто пользователи будут ожидать, то это мне походит
5
10 августа 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: vitaliy_lyakh
hardcase, всё таки Access уникален, если писать под .NET

Чем же он уникален, простите?

Если у вас планируется 50 одновременный пользователей, то приложение сервер-то скорее всего будет стационарным и смысл ограничения в отсутствии зависимости от сервера БД теряется, а развернуть тот же MsSql2005 Express обычно ничего не стоит.

Использование полноценного СУБД или использование in-proc движка БД - это скорее вопрос сложности вашей системы. Чем сложнее система - тем больше звеньев в ней можно выделить. При реализации схемы с СУБД вы получаете классическую трехзвенную (не путать с уровнями) архитектуру: Клиент - сервер - СУБД. В противном случае - двухзвенную.

341
11 августа 2008 года
Der Meister
874 / / 21.12.2007
Система на 50 одновременных сетевых подключений уже подходит под определение корпоративной, и смысла НЕ ставить промышленную СУБД я, честно говоря, не вижу (даже рашн 1С придерживается такого же мнения :D)
Впрочем, я уже упоминал, что, используя интеграцию c CLR в MS Sql Server, примерно в 85% случаев можно свести систему к виду клиент-СУБД (СУБД=сервер)
5
11 августа 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: Der Meister
Впрочем, я уже упоминал, что, используя интеграцию c CLR в MS Sql Server, примерно в 85% случаев можно свести систему к виду клиент-СУБД (СУБД=сервер)

Вот всегда интересовал вопрос целесообразности использования CLR в MSSql2005/2008. Насколько оправданно создавать подобные хранимые процедуры, ведь с БД взаимодействовать всеравно придется посредством SQL?
Да, я понимаю что сложную математику - какуюнить хитрую агрегирующую функцию - или нетривиальный изврат над строкой (Regex вдруг применить) очень удобно организовывать в .NET. Но как можно выполнить почти всю логику приложения в этом стиле без ущерба для концепции "модели предметной области"?


З.Ы. Вопрос в принципе достоин отдельной ветки.

26K
11 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
А такой вопрос...если не брать во внимание количество одновременных пользователь, пусть есть приложение под .NET, и оно оперирует большими объемами данных. Главное для разработчика - переносимость и прозрачность кода.

Что лучше выбрать? Сериализацию, обычную работу с файловым потоком, или базу данных (без сервера). Если базу, то, выходит, только Access?

Скорость выборки и изменения данных коечно важна, но не критична.

З.Ы. Просто интересно:) Прошу всех высказаться, кто что предпочитает
11
11 августа 2008 года
oxotnik333
2.9K / / 03.08.2007
Цитата: vitaliy_lyakh
А такой вопрос...если не брать во внимание количество одновременных пользователь, пусть есть приложение под .NET, и оно оперирует большими объемами данных. Главное для разработчика - переносимость и прозрачность кода.

Что лучше выбрать? Сериализацию, обычную работу с файловым потоком, или базу данных (без сервера). Если базу, то, выходит, только Access?

Скорость выборки и изменения данных коечно важна, но не критична.

З.Ы. Просто интересно:) Прошу всех высказаться, кто что предпочитает


С точки зрения простоты и быстроты разработки думаю лучше БД подойдет.
За сериализацию не скажу - не знаю.
С файлавыми потоками - имхо приличный гемор (хотя все зависит от схемы данных) + сложности в понимании кода.

5
11 августа 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: vitaliy_lyakh
Главное для разработчика - переносимость и прозрачность кода.

1) что вы понимаете под переносимостью?
2) Что для вас прозрачность кода?

Есть два аспекта переносимости: между машинами с одной и той же ОС, между разными ОС. Вас какой интересует? Перенести грамнотно спроектированное .net приложение на машину с другой виндой дело нехитрое, уверяю вас - *.config файл вам в этом поможет. Перенос между ОС уже сложный вопрос, так как вам, чтобы минимизировать растрату нервов и времени, придется разрабатывать сразу на Mono и учитывать его особенности и выбирать СУБД также учитывая эту специфику.

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

Цитата: vitaliy_lyakh
Сериализацию, обычную работу с файловым потоком, или базу данных (без сервера).

1) сериализация. Что вы понимаете под сериализацией. Есть 2 вида: двоичная и xml. Двоичная - почти бесплатный механизм сохранения/восстановления всего чего пожелает бренная душа. Xml-сериализация более накладна и мене функциональная, используется в случаях с web-приложениями и сервисами. Я не люблю XML.
2) прямая работа с файловыми потоками - отстой. Двоичная сериализация позволяет скрыть ее.
3) Что в к Аксессу прицепились, ну не пуп земли это! Это в первую очередь НАСТОЛЬНАЯ БД, делать сервер чеголибо на нем - уже сомнительная затея. Гораздо удобнее использовать или полноценные БД, если система большая, или встраиваемые движки - если данных немного (ну, относительно) и требуется скорость выполнения реляционных операций над ними.
При хорошем подходе можно почти бесплатно получить десериализацию объектов из результатов работы запросов к БД, это я на LINQ намекаю, хотя и сам реализовал интеграцию вызова хранимок в .NET и почти "бесплатное" обертываение результатов в объекты (без линкью, Fw 2.0).

26K
13 августа 2008 года
vitaliy_lyakh
33 / / 03.11.2007
Цитата: hardcase
1) что вы понимаете под переносимостью?
2) Что для вас прозрачность кода?



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

Код прозрачный, если в нем без особого труда разберётся другой человек.

Цитата: hardcase
1) Xml-сериализация более накладна и мене функциональная



Почему вы так считаете?

Преимуществами XML-документа являются его читабельность и хорошо развитые средства разбора, но зато бинарное представление выигрывает в объеме и скорости передачи тех же данных.

8.2K
13 августа 2008 года
Ora-cool
211 / / 20.09.2007
Короче. Для 50-100 одновременных коннектов нужно выбирать клиент-серверную СУБД и не парить себе моск :)
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог