Выбор ISAM вместо SQL

Конечно, бывают моменты и места, когда ISAM предоставляет услуги, необходимые приложению, с меньшими затратами и накладными расходами, чем полноценная СУБД SQL. Одним из недостатков механизма ISAM является то, что для описания данных не обязательно иметь системный каталог; во-вторых, обычно существует несколько удобных инструментов для доступа к данным. В обоих случаях СУБД дает значительные преимущества. Лучшие системы ISAM (или аналогичные) обеспечивают поддержку транзакций - иногда даже транзакций XA.

Там, где вам нужно выполнить сложные соединения и вычисления (например, агрегаты), работа, выполняемая СУБД, дает огромные преимущества. Там, где все, что вам нужно, это доступ к записям, ISAM может оказаться полезным.

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

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

Я реализовал библиотеку ORM-to-isam еще в 1990-х годах, которая пользовалась некоторым (очень) скромным успехом в качестве условно-бесплатного ПО. Я в целом согласен с тем, что вы говорите о достоинствах ISAM, и я думаю, что лучше использовать ISAM при создании уровня или продукта ORM, если вы ищете только гибкость и скорость.

Однако вы рискуете потерять все преимущества широкого спектра продуктов, связанных с SQL, которые сейчас присутствуют на рынке. В частности, инструменты отчетности стали более тесно интегрированными с наиболее популярными пакетами SQL. В то время как поставщики продуктов ISAM в 1990-х предоставляли драйверы ODBC для интеграции с такими продуктами, как Crystal Reports, даже тогда казалось, что рынок отклоняется от ISAM, и что я рискую устареть, если продолжу использовать эту технологию. Таким образом, я перешел на SQL.

Одно предостережение: прошло почти десять лет с тех пор, как я играл в песочнице ISAM, поэтому я не могу претендовать на то, чтобы быть в курсе последних инструментов ISAM и их решений этой проблемы. Однако, если я не был уверен, что не попаду в ловушку без поддержки инструментов отчетности, я бы не стал применять ORM на основе ISAM, независимо от его достоинств. И это даже не касается других инструментов, доступных для разработки на основе SQL!

Может быть, Pig Latin - это то, что вам нужно? Согласно этой статье http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=693D79B5EFDC0452E1C9A87D1C495D4C?doi=10.1.1.124.5496&rep=rep1&type=pdf:

"Besides, many of the people who ana- lyze this data are entrenched procedural programmers, who find the declarative, SQL style to be unnatural. The success of the more procedural map-reduce programming model, and its associated scalable implementations on commodity hard- ware, is evidence of the above. However, the map-reduce paradigm is too low-level and rigid, and leads to a great deal of custom user code that is hard to maintain, and reuse. We describe a new language called Pig Latin that we have designed to fit in a sweet spot between the declarative style of SQL, and the low-level, procedural style of map-reduce."

Я сделал свою долю dBase, Clipper и FoxPro. Однако я считаю, что реляционная модель, предоставляемая SQL, неизмеримо мощнее и полезнее, а такие продукты, как Oracle и SQL Server, заслуживают своего успеха на рынке.

Я всегда удивляюсь, почему люди так усердно создают слой сопоставления для ~ 80-90% случаев и пишут 10-20% пользовательского SQL для обработки сложных запросов (в основном отчетов) и пакетного перемещения данных. Я должен делать что-то действительно хорошее или что-то действительно глупое, принимая модель DAL / DAO, учитывая уровень ненависти к спящему режиму, активной записи и т. д. - см. Обсуждение Вьетнама ранее.

Кому-нибудь нужна многозначная база данных? (также известный как Pick) Думайте об XML без тегов. Они появились раньше, чем РСУБД, по крайней мере, на десять лет и все еще остаются сильными, если вы знаете, где искать.

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

С увлечением NoSQL (да, я сказал это ... помешательством) это не означает, что мы не можем моделировать ISAM-подобный доступ внутри РСУБД. Вы будете уверены, что я перенесу в БД столько логики, сколько смогу, но бывают такие моменты, как "традиционная" сетка данных / многомерная интерполяция данных, когда я просматриваю все необходимые записи через мою собственную логическую схему. индекс.

Если вы точно знаете, что вы хотите делать со своими данными и как вы хотите это делать, выберите ISAM. Вы будете счастливы, потому что вы структурируете свои индексы так, чтобы они точно соответствовали вашим потребностям. Знайте заранее, что если ваши потребности изменятся, вы захотите изменить свою индексацию. Доступ к данным будет молниеносным.

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

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