Выбор субд
В приложении строка подключения должна указывать на файл базы, находящийся в каталоге приложения.
Слышал, что Access поддерживает до 50 одновременных подключений. Не понимаю, как это? Раз база работает и без сервера. Объясните!
Для выбора СУБД нужно проанализировать множество критериев - назначение БД (список решаемых задач), режимы работы, требования к надежности и отказоустойчивости, стоимость/бесплатность СУБД, сложности администрирования и т.д. и т.п.
Аналогично предложу SqlServerCompact (Тот что раньше был мобайлом).
А если она вовсе и не настольная, то можно просто заключить всю бизнес-логику в нормальную СУБД (используя, к примеру, CLR хранимые поцедуры MS SQL Server) и получить единое серверное приложение. Устанавливать придётся только его.
А разве удобнее будет использовать простые файлы, чем бд, пусть даже жертвуя скоростью?
Можете об этом поподробнее? Не совсем понял, как это избавит от установки сервера бд?
http://ru.wikipedia.org/wiki/SQL_Server_Compact_Edition
"SQL CE не оптимизированна для большого количества одновременных пользователей"
"Многопользовательская работа с одним файлом базы данных с разных компьютеров — не поддерживается в связи с техническими сложностями"
А разве драйвер для Access (2000-2003) не устанавливается вместе с NET Framework?
Во вторых, я не знаю, так как я НЕ использую .NET и пишу в основном на чистом С
Если так, как вы говорите, то вам лучше использовать Access, так как для SQLite вам прийдется писать/искать врапер под данную платформу
Использовать ли его или нет - решать только вам.
Попробуйте и сравните разные варианты.
Если же поджимает время, ИМХО, лучше использовать то, с чем приходилось работать
"SQL CE не оптимизированна для большого количества одновременных пользователей"
"Многопользовательская работа с одним файлом базы данных с разных компьютеров — не поддерживается в связи с техническими сложностями"
Многопользовательский доступ к БД реализуется на уровне процесса-хоста, в котором работает движок БД.
Если у вас такая уйма клиентов (порядка сотни), то может быть имеет смысл исползовать нормальную СУБД типа Sql Server 2005? Можно даже и бесплатную версию - ее вам точно хватит.
З.Ы. А аксесс у вас загнется нахрен :))
Чем же он уникален, простите?
Если у вас планируется 50 одновременный пользователей, то приложение сервер-то скорее всего будет стационарным и смысл ограничения в отсутствии зависимости от сервера БД теряется, а развернуть тот же MsSql2005 Express обычно ничего не стоит.
Использование полноценного СУБД или использование in-proc движка БД - это скорее вопрос сложности вашей системы. Чем сложнее система - тем больше звеньев в ней можно выделить. При реализации схемы с СУБД вы получаете классическую трехзвенную (не путать с уровнями) архитектуру: Клиент - сервер - СУБД. В противном случае - двухзвенную.
Впрочем, я уже упоминал, что, используя интеграцию c CLR в MS Sql Server, примерно в 85% случаев можно свести систему к виду клиент-СУБД (СУБД=сервер)
Вот всегда интересовал вопрос целесообразности использования CLR в MSSql2005/2008. Насколько оправданно создавать подобные хранимые процедуры, ведь с БД взаимодействовать всеравно придется посредством SQL?
Да, я понимаю что сложную математику - какуюнить хитрую агрегирующую функцию - или нетривиальный изврат над строкой (Regex вдруг применить) очень удобно организовывать в .NET. Но как можно выполнить почти всю логику приложения в этом стиле без ущерба для концепции "модели предметной области"?
З.Ы. Вопрос в принципе достоин отдельной ветки.
Что лучше выбрать? Сериализацию, обычную работу с файловым потоком, или базу данных (без сервера). Если базу, то, выходит, только Access?
Скорость выборки и изменения данных коечно важна, но не критична.
З.Ы. Просто интересно:) Прошу всех высказаться, кто что предпочитает
Что лучше выбрать? Сериализацию, обычную работу с файловым потоком, или базу данных (без сервера). Если базу, то, выходит, только Access?
Скорость выборки и изменения данных коечно важна, но не критична.
З.Ы. Просто интересно:) Прошу всех высказаться, кто что предпочитает
С точки зрения простоты и быстроты разработки думаю лучше БД подойдет.
За сериализацию не скажу - не знаю.
С файлавыми потоками - имхо приличный гемор (хотя все зависит от схемы данных) + сложности в понимании кода.
1) что вы понимаете под переносимостью?
2) Что для вас прозрачность кода?
Есть два аспекта переносимости: между машинами с одной и той же ОС, между разными ОС. Вас какой интересует? Перенести грамнотно спроектированное .net приложение на машину с другой виндой дело нехитрое, уверяю вас - *.config файл вам в этом поможет. Перенос между ОС уже сложный вопрос, так как вам, чтобы минимизировать растрату нервов и времени, придется разрабатывать сразу на Mono и учитывать его особенности и выбирать СУБД также учитывая эту специфику.
Прозрачность. Для меня вот порой бывает прозрачным код с кучей параметрических классов и анонимных делегатов. Хотя конечно все зависит от количества уровней ответственности классов и методов, чем меньше уровней - тем прозрачней код, в то же время, чем абстрактнее класс - тем проще понять его место в системе, но иерархия абстракций влечет за собой увеличение уровней ответственности. Читайте МакКоннелла - все поймете.
1) сериализация. Что вы понимаете под сериализацией. Есть 2 вида: двоичная и xml. Двоичная - почти бесплатный механизм сохранения/восстановления всего чего пожелает бренная душа. Xml-сериализация более накладна и мене функциональная, используется в случаях с web-приложениями и сервисами. Я не люблю XML.
2) прямая работа с файловыми потоками - отстой. Двоичная сериализация позволяет скрыть ее.
3) Что в к Аксессу прицепились, ну не пуп земли это! Это в первую очередь НАСТОЛЬНАЯ БД, делать сервер чеголибо на нем - уже сомнительная затея. Гораздо удобнее использовать или полноценные БД, если система большая, или встраиваемые движки - если данных немного (ну, относительно) и требуется скорость выполнения реляционных операций над ними.
При хорошем подходе можно почти бесплатно получить десериализацию объектов из результатов работы запросов к БД, это я на LINQ намекаю, хотя и сам реализовал интеграцию вызова хранимок в .NET и почти "бесплатное" обертываение результатов в объекты (без линкью, Fw 2.0).
2) Что для вас прозрачность кода?
Может я не то слово написал, но под переносимостью имел ввиду возможность работы приложения на одной ос, то есть на флешку его кинуть, и запускать на разных машинах, где есть Framework, о UNIX речи не идёт.
Код прозрачный, если в нем без особого труда разберётся другой человек.
Почему вы так считаете?
Преимуществами XML-документа являются его читабельность и хорошо развитые средства разбора, но зато бинарное представление выигрывает в объеме и скорости передачи тех же данных.