Выбор ISAM, а не SQL

Question

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

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

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

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

Answer 1

Может Pig Latin это то, что вы хотите? По этой статье http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=693D79B5EFDC0452E1C9A87D1C495D4C?doi=10.1.1.124.5496&rep=rep1&type=pdf:

Кроме того, многие из тех, кто Лизе эти данные укоренились процедурные программисты, которые находят декларативный, стиль SQL будет неестественно. Успех более процедурное картографическое программирование модель и связанный с ней масштабируемый реализации на товарных посуда, является доказательством вышесказанного. Тем не менее, парадигма сокращения карты слишком низкий уровень и жесткий, и приводит к большое количество пользовательского кода, который трудно поддерживать и использовать повторно. Мы описать новый язык под названием свинья Латынь, которую мы разработали, чтобы соответствовать сладкое пятно между декларативным стиль SQL и низкоуровневый, процедурный стиль карты-уменьшить. "

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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