@FasterHarder

Всем привет! Сходу к делу!
Много читал и запутался в итоге)

Постараюсь коротко и самую суть. Есть программа MS Access. Поставляется вместе с пакетом MS Office. В Access удобно создавать настольные приложения. Можно создать БД + интерфейс к ней. Как понимаю, вся информация о данных + метаданных БД хранится в файле *.mdb (microsoft database).

Клиент-серверная архитектура (классическая двузвенка): на "тонком" клиенте интерфейс, который программируется, например, на C#, на "толстом" сервере лежат данные в виде базы данных. Также на сервере специализированное ПО вида СУБД/СУРБД. Вообще, если грубо, под сервером я понимаю более производительный комп + спец.ПО.

Считается, что MS Access заточен под файл-серверную технологию, а разве нельзя преобразовать ее в клиент-серверную. Например, клиент на C#, на сервере файл *.mdb.

Как я понимаю, *mdb файл с данными, но там нет встроенного интерпретатора анализа запросов и пр., т е того, что встроено в MS SQL Server, например.

Пример: у меня есть 2 компа (пусть 1 более мощный, типа он будет выступать Сервером). На Сервере нет инсталлированного пакета MS Office. У меня есть БД с расширением *.mdb, который я кладу в какую-нибудь папку на Сервер. На клиенте есть C#. Я ведь могу, используя, например, поставщик OLEDB, ODBC с клиента подключится к файлу баз данных *.mdb, располагающегося на Сервере и получать данные посредством технологии ADO.NET?? Это будет считаться клиент-серверной технологией, когда на клиенте C#, а на Сервере БД акссессовская??

P.S. про всякие Jet движки не стал писать и пр., но думаю итак понятно, что я спрашиваю)

0

@Grossmeister

Главное отличие "нормальной" СУБД от персональной СУБД - это производительная работа в многопользовательском режиме, причем желательно, чтобы число возможных пользователей измерялось не единицами, а десятками - тысячами. Access вроде поддерживает многопользовательский режим (сам не пробовал, только читал на форумах), но делает это довольно слабо, поскольку изначально позиционировался именно как персональная СУБД.

0

@FasterHarder

да, Access поддерживает multyconnect!
спс за комментарий, но мне не стало яснее)

0

@Grossmeister

Все зависит от того, что ты хочешь узнать и от задач, которые хочешь реализовать. Может Access работать как многопользовательская СУБД? Может. Если у тебя несколько пользователей, которые периодически заходят в БД и вводят достаточно небольшой объем инфы, а также формируют простенькие отчеты, то возможно что Access и подойдет. Если у тебя реальная учетная система с хотя бы полусотней пользователей, тысячами транзакций в сутки и таблицами с миллионами строк, то любой здравомыслящий человек Access использовать не будет, для этого есть другие СУБД, пусть и за бОльшие деньги.

0

@FasterHarder

Grossmeister, я понял) я не про это вообще спрашиваю...

0

@Grossmeister

Именно. В СУБД есть масса процессов, которые на сервере занимаются много чем. Скажем, в Oracle больше десятка фоновых серверных процессов плюс стартует процесс на каждую сессию (который и выполняет обслуживание запросов клиентов). В Access ты с клиентской программы просто работаешь с файлом данных, неважно, лежит он локально или на сервере. То есть клиентская программа формирует запросы и сама же формирует ответы, что не есть клиент-сервер.

0

@FasterHarder

так, на 5% приблизились к моим вопросам, но пока еще очень и очень холодно)...
я ведь очень четко задал вопросы + даже пример привел + про ОДБС/ОЛЕБД немного чирканул...

0

@Usaga

Можно, но нужно быть в ссоре с головой.

Вы же осознаёте (вопрос риторический), что файл *.mdb - просто файл с данными, база. Для работы с ней нужна СУБД, которая будет выполнять ваши SQL-запросы, будет знать как работать с этим файлом и всё такое прочее?

Нет, не будет никаким боком. Ваш сервер СУБД будет располагаться на клиенте (OLEDB, Jet), а с сервера просто будет вытягиваться файл для работы локально. Т.е. такой сервер не сервер, а просто отдаватель файла. Он может быть хоть на базе сорокоядерного Xeon, хоть в виде мобильного телефона, разницы не будет, он только отдаёт файл, работы "серверной" никакой не совершает.

0

@FasterHarder

а вот тут поподробнее.
Т е, если использую поставщик, ну, пусть универсальный ОДБС, то он ЗАКАЧИВАЕТ полностью файл *.mdb с Сервера на Клиента, потом извлекает информацию, запоминает где-то в памяти, а файл пересылает ОБРАТНО на сервер и отображает данные из памяти. Примерная такая схема, да? Если да, то тогда констатируем, что Access, это ВСЕГДА файл-серверная вещь для создания настольных приложений. А как же adp или как там он правильно называется...

0

@Usaga

FasterHarder, SMB позволяет работать с отдельными частями файла, не выкачивая его целиком. Но смысл не меняется. "Сервер" просто отдаёт части файла и всё, никакой работы с базой он не совершает, ибо на нём даже ПО такого не присутствует.

Сама СУБД вшита в драйвер OLEDB\Jet, ибо относительно простая (персональная же). Т.е. настоящим сервером выступает сам клиент. Никакой клиент-серверной архитектуры нет и в помине.

Если вам нужно именно клиент-серверную архитектуру организовать, то это делается из ТРЁХ частей: клиента, сервера (на C# или любом другом языке) и самой СУБД. Сервер СУБД может торчать на той же машине, что и сервер приложения. Если это MS Access, то иного и быть не может - MS Access или Jet должен быть на той же машине, что и сервер приложения.

Но это дичь лютейшая. MS Access вообще не для таких применений. Возьмите нормальную серверную СУБД, благо, что их как грязи, и даже у платных есть бесплатные редакции.

1

@FasterHarder

Usaga, давай проясним еще следующие моменты.
1. Чтобы работать с базой файла *.mdb нужна инсталляция на этой машине MS Access (в него ведь встроена локальная СУРБД, ну там всякие анализаторы, интерпретаторы, роли, права и пр. пр.)?
2. Возможна ведь связка следующая: "толстенный" сервер MS SQL Server + "тончайший" клиент MS Access? Это уже будет классическая архитектура сервер + клиент (или наоборот, не суть )
3. Если создана БД на Access и нет ее возможности преобразовать в др. БД, то клиент ОБЯЗАНЫ создавать также на Access + забыть про клиент-сервер, так, да?

0

@Usaga

FasterHarder,
1. На машине, которая будет работать с файлом, должен стоять или MS Access или OLEDB\Jet (которые ставятся, обычно, ставятся с MS Access).

Шта?...

3. Мигрировать данные из Access можно в любую другую СУБД. Может для этого даже и готовые инструменты есть, я не знаю. Но если и нету, то можно через OLEDB\Jet вытащить данные из всех таблиц и отправить в другую СУБД.

0

@FasterHarder

ну ты чего, ну стандарт ведь) клиент (Аксес) + сервер (БД под управлением MS SQL Server)...

я знаю, что можно, но, если "нельзя", то клиента ваять нужно на Аксес, т к это крайне удобно...

РЕЗЮМЕ: Access заточен под файл-сервер (хотя там еще АДП есть разбивка), поэтому, если нужен классический клиент+сервер, то смотреть нужно в сторону SQL Server/Oracle, а клиента ваять на том языке, который хорошо знаешь, в том числе и Access...ну так ведь, да? ну должно быть так!

0

@Usaga

FasterHarder, делать клиент на Access? Для SQL Server это скорее всего возможно. Но это дичь какая-то, если честно.

0

@FasterHarder

это бывает НОРМАЛЬНАЯ, вкусная дичь)
меня интересует сам факт, что это возможно)

И крайний вопрос: допустим сделали БД + интерфейсы под Access. Этой прогой должны пользоваться 15 юзеров. Что делаем? Инсталлим у них у всех MS Access, затем выделяем Сервер, туда кладем *.mdb или придется раздать всем копии на эти 15 компов этой БД? Я не знаю, репликации поддерживает Аксес, вроде частично, хотя хз...

0

@Usaga

FasterHarder, если у каждого будет своя копия базы... То как другие пользователи будут видеть работу друг друга?

Дичь нормальной не бывает никогда.

Я так понимаю, что речь идёт о том, чтобы не оплачивать разработку нормальной ИС, а украсть на торрент-треккере офисный пакет на сумму разработки этой самой ИС и воткнуть всем пользователям? Хоть бекапы, тогда, делайте почаще...

0

@FasterHarder

неправильно понимаешь!

никак. Значит нужно взять 1 файл *.mdb положить на Сервант и обеспечить удаленный доступ с 15 компов. Только я не знаю, там всякие блокировки, изоляции как будут. В MS SQL Server прекрасно все это работает.

В общем ладно, Usaga, спс. за помощь! Мне не все понятно и я далеко не все осознал глубоко, но кое-что я понял))

0

@Usaga

С этим будет максимально сложно) Несколько процессов будут пытаться одновременно работать с одним файлом.

Тогда почему не сделать нормально?

0

@FasterHarder

я вообще прогаю на связке C# + SQL Server 2000/2008, но мне стало чисто любопытно, а можно ли взять C# + Access, оказалось, что НЕТ)

0

@Usaga

FasterHarder, я вроде бы сказал, что можно. Только OLEDB\Jet должен стоять на сервере приложения. Или я этого не говорил?)

Добавлено через 1 минуту
А с SQL 2012 и выше вы работать уже не можете?))

1