Выбор ISAM, а не SQL

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

тем не менее, мне кажется, что многие методы для решения "несоответствия импеданса" между двумя парадигмами были бы намного лучше подходят для набора инструментов ISAM (метод индексированного последовательного доступа), где вы можете (должны) указать таблицы, индексы, row-naviagation, etc. открыто-именно то поведение, которое предписывается моделью ActiveRecord, например.

в первые дни ПК dBASE и ее потомство были доминирующими платформами СУБД, и это был улучшенный ISAM. Foxpro продолжает эту линию довольно успешно до сегодняшнего дня. MySQL и Informix-это два RDBMSs, которые были по крайней мере изначально построены поверх реализаций ISAM, поэтому этот подход должен быть по крайней мере одинаково эффективным. У меня такое чувство, что многие разработчики, которые недовольные SQL, по крайней мере, бессознательно стремятся к возрождению подхода ISAM, и базу данных можно было бы легче рассматривать как набор массивно эффективных связываемых гипер-массивов. Мне кажется, это действительно хорошая идея.

вы когда-нибудь пробовали, скажем, реализацию ORM-to-ISAM? Насколько успешно? Если нет, как вы думаете, стоит попробовать? Существуют ли какие-либо наборы инструментов для этой модели явно?

6
isam orm sql

7 ответов

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

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

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

1

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

"кроме того, многие из людей, которые Ана- lyze эти данные закреплены процедурные программисты, которые находят декларативный, стиль SQL должен быть неестественный. Успех the more процедурная карта-сокращение программирования модели и связанные с масштабируемостью реализация на товарном рынке- ware, является свидетельством вышесказанного. Тем не менее, парадигма map-reduce слишком низкоуровневый и твердый, и водит к много пользовательского кода, который трудно поддерживать и повторно использовать. Мы опишите новый язык под названием Pig Латынь, которую мы разработали, чтобы вписаться в сладкое пятно между декларативным стиль SQL, и низкоуровневый, процедурный стиль карты-reduce."

3

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

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

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

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

2

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

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

1

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

1

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

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

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

1

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

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

0