Действительно ли Доступ MS (СТРУЯ) подходит для многопользовательского доступа?

Вы должны использовать .text()/.html(), потому что не имеет значения свойства

var meta_keyword_it=$('#meta_keyword').text();
alert(meta_keyword_it);
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<div id="tag" >
<tags-input  v-model="tags" id="meta_keyword" >dfg</tags-input>
</div>

17
задан Romias 18 April 2009 в 18:44
поделиться

12 ответов

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

  1. Механизм базы данных Jet (это все, что здесь задействовано, как пояснил OP с редактированием) по умолчанию является многопользовательским - он был построен с нуля таким образом.

  2. совместное использование хранилища данных Jet очень надежно, когда сеть не соответствует стандартам. Это означает не WAN и не беспроводной, потому что пропускная способность должна быть достаточной для того, чтобы Jet поддерживал файл LDB (для многопользовательской блокировки), что означает пинг экземпляром ядра базы данных Jet вашего локального ПК один раз в секунду (с настройками по умолчанию), и потому что Jet может ' • восстановление после сброшенного соединения (что довольно часто встречается в беспроводной среде).

  3. ситуация, когда Access падает, - это когда общий доступ к MDB приложения Access (это не так для этого автора). Причина, по которой это не удается, заключается в том, что вы делитесь вещами, которые не могут быть надежно предоставлены и у которых нет причин для совместного использования. Поскольку объекты Access хранятся в файле MDB (весь проект Access хранится в одном поле BLOB в одной записи в одной из системных таблиц), он очень подвержен повреждению, если его открывают несколько пользователей. По моей оценке, Совместное использование внешнего интерфейса Access (или неразделенного MDB с таблицами и формами / отчетами / и т. д. в одном MDB) является источником 99,99% повреждений файлов Access / Jet.

Мой основной ответ на вопрос OP: что, да, Jet будет отличным хранилищем данных для приложения такого размера. Однако, если существует какая-либо возможность для роста числа пользователей выше 25, то, возможно, было бы лучше начать с нуля с помощью механизма базы данных, который более устойчив при более высоких группах пользователей.

26
ответ дан 30 November 2019 в 10:39
поделиться

Это вполне выполнимо; но вы ДОЛЖНЫ разделить базу данных на внешний интерфейс (с формами, запросами, кодом) и внутренний (только данные). Каждый пользователь должен иметь интерфейс на своем компьютере, связывающийся с общим сервером.

Это будет медленно, поскольку Jet генерирует тонну сетевого трафика. Microsoft также постепенно осуждает Access как инструмент разработки. Например, Access 2007 имеет гораздо менее сложную модель безопасности, чем Access 2003.

Как давний разработчик Access, я постепенно отхожу от Access.

7
ответ дан 30 November 2019 в 10:39
поделиться

Не делайте этого ... База данных Jet утверждает, что может поддерживать несколько пользователей, но невероятно легко использовать мастер изменения размера для преобразования файла Access в базу данных Sql Express. Этот файл базы данных может быть легко заблокирован пользователем или администратором, и все ваши пользователи не смогут использовать базу данных.

... и Sql Express бесплатен . Оттуда ваш путь обновления до полного экземпляра Sql Server или другой коммерческой базы данных прост.

6
ответ дан 30 November 2019 в 10:39
поделиться

Двигатель ACE / Jet является отличным программным обеспечением, но, хотя он был и предназначен для поддержки нескольких пользователей, фактически поддержка нескольких пользователей на практике не является его сильные стороны. Последняя капля для меня - то, где затем удалили защиту уровня пользователя (ULS) из движка: я предполагаю, что могу представить себе простую ситуацию с базой данных, когда все пользователи будут иметь одинаковые привилегии (то есть доступ администратора ко всем объектам базы данных ) но IMO, которая не поддерживает нескольких пользователей, по сравнению, скажем, с MS SQL Server.

2
ответ дан 30 November 2019 в 10:39
поделиться

С 2 или 3 пользователями в надежной локальной сети у вас все будет хорошо, если вы часто выполняете резервное копирование сетевого диска.

Избегайте любых полей бит / бул в ваших таблицах - Jet имеет некоторые неприятные проблемы с коррупцией при множественном доступе к ним.

Также имейте в виду, что вся блокировка в Access является оптимистичной: иногда вы будете получать грязные чтения.

MS Access разработан для небольших офисных сценариев, таких как: некритично легкое офисное использование, которое вы можете настроить с минимумом программирования.

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

6
ответ дан 30 November 2019 в 10:39
поделиться

Да, он поддерживает доступ нескольких (то есть небольшого числа рабочей группы) пользователей через общий сетевой файл. Однако архитектура общего файлового ресурса просто не идеальна для поддержки одновременной записи в файл несколькими пользователями. Система клиент-серверной базы данных (SQL Server и т. Д.) Обычно обеспечивает более высокую производительность, безопасность и надежность.

1
ответ дан 30 November 2019 в 10:39
поделиться

Это было сделано очень много раз многими инженерами-разработчиками универсального программного обеспечения, когда мы видели, как .mdb портился в многопользовательская ситуация. Если многие опытные разработчики Access могут сделать это правильно, как я склонен верить, то мы, универсалы, должны делать что-то не так, и что-то должно быть довольно фундаментальным, но неочевидным, чтобы многие из нас убегали от этой вещи. кричит "Никогда больше!" Так что, если вы считаете себя опытным специалистом-разработчиком Access (или знаете, как его найти), сделайте это. Но если вы универсальный или случайный пользователь, ищущий легковесный бэкэнд, то я советую вам поискать что-то другое (SQL Server - хороший IMO).

1
ответ дан 30 November 2019 в 10:39
поделиться

Если ваши пользователи могут вдвое дольше ждать приложения с половиной нужных им функций, то не используйте Доступ.

1
ответ дан 30 November 2019 в 10:39
поделиться

Как системный администратор, пожалуйста, не используйте Access для чего-либо многопользовательского. Делайте то, что предлагает Джефф Фриц, и используйте базу данных, предназначенную для многопользовательского доступа. Вы можете подумать, что ваше маленькое приложение будет доступно только нескольким людям, но я гарантирую, что к концу года у него будет сто пользователей и пятьдесят новых функций. И если это все Access, а не VB / SQL Express, ваши сотрудники Ops однажды ночью ворвутся в ваш дом и перережут вам глотку.

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

1
ответ дан 30 November 2019 в 10:39
поделиться

У Jet нет сложной логики блокировки, необходимой для поддержки многопользовательских сценариев. Вы можете обойтись без использования его, если ваше приложение в основном читает и с низким уровнем конкуренции.

Я видел, что веб-сайты поддерживают много пользователей, но я бы порекомендовал SQL Express, если у вас нет веских причин выбрать Jet.

0
ответ дан 30 November 2019 в 10:39
поделиться

Если вы используете сервер терминалов, производительность действительно хороша. У нас есть больше решений до 50 пользователей в одном Access mdb. Разработка происходит очень быстро, а развертывание легко.

Проблемы:

  • каждый может копировать данные mdb
  • без прав доступа
  • ограниченные процедуры хранения
  • оптимизировать (сжатие и восстановление) возможно только без использования базы данных данных
  • ограничение до 2 ГБ!
0
ответ дан 30 November 2019 в 10:39
поделиться

Я могу сказать вам по болезненному опыту, что Jet 3/3.5 не был надежным приложением. Я видел, как он часто падал под легкой нагрузкой, а когда случались аварии, вы рисковали повредить данные. Раньше он был чрезвычайно чувствителен к любым проблемам с питанием, к любым авариям клиентов (даже пользовательский интерфейс, связанный с mdb), и к любым проблемам в локальной сети. Более свежие версии Jet могут быть лучше, но переход на Sql Server, на мой взгляд, явно подходит для чего угодно, кроме тривиального ввода данных с небольшим количеством пользователей. Sql Express бесплатен, и вы на самом деле ничего не теряете, особенно если ваш пользовательский интерфейс находится в .Net, а не в Access.

EDIT: Microsoft считает, что вам также не стоит полагаться на Jet 4.

с: http://support.microsoft.com/kb/303528

Microsoft Jet не предназначена для использования с высоконагруженными серверными приложениями, высоковалютными серверными приложениями, или 24 часа в сутки, семь дней в неделю серверными приложениями. Сюда входят серверные приложения, такие как веб-приложения, коммерческие приложения, транзакционные приложения и приложения для серверов обмена сообщениями. Для таких типов приложений лучшим решением является переход на настоящую систему баз данных на основе клиент/сервер, такую как Microsoft Data Engine (MSDE) или Microsoft SQL Server. Когда вы используете Microsoft Jet в приложениях с высокой нагрузкой, таких как Microsoft Internet Information Server (IIS), вы можете столкнуться с любой из следующих проблем: Повреждение базы данных Проблемы со стабильностью, такие как сбой или блокировка IIS. Внезапный отказ или постоянный отказ драйвера подключиться к действительной базе данных, требующий перезапуска службы IIS

.
0
ответ дан 30 November 2019 в 10:39
поделиться
Другие вопросы по тегам:

Похожие вопросы: