Файлы компонентов APL против собственных файлов и баз данных
Я новичок в APL и начинаю работать на базе кода APL, которая использует файлы компонентов APL (например, ⎕FSTIE, ⎕FREAD, ⎕FAPPEND) сильно Меня также попросили изучить возможность передачи содержимого этих файлов компонентов в базу данных SQL, цель которой - сделать данные доступными для других приложений.
Некоторые из файловых компонентов содержат текст, который на первый взгляд выглядит так, как будто он будет работать нормально, если хранится в собственном файле, но основная часть файлов компонентов в основном содержит "неправильные" числовые матрицы, которые кажутся мне случайными, что в конечном итоге будет реализован как одна таблица DB2 для каждого компонента. Самым большим до сих пор было что-то вроде 500 строк х 20 столбцов. Я еще (сознательно) не видел никаких вложенных массивов, хотя я только слегка поцарапал поверхность. Пока что только символьный текст и числовые векторы и матрицы.
Будет ли разумным вариантом перенести содержимое этих файлов компонентов в Native Files? Зачем вообще использовать файлы компонентов APL?
Используемая система APL - Dyalog APL под Windows 7. Она существует уже давно, и никто не уверен, как долго.
2 ответа
Преимущество использования файлов компонентов заключается в том, что вы можете читать / записывать любой APL-массив (настолько сложный и настолько большой, насколько вам нужно) с помощью одной встроенной операции в / из файла, тогда как вам может потребоваться написать свои собственные выделенные функции, если вы хотите сделать это для большого, сложного массива в формате.TXT или.XML. (К счастью Дьялога ⎕CSVа также ⎕XML сделаю это за вас, но с точки зрения производительности файлы компонентов почти наверняка победят.)
Первая файловая система была разработана совместно в конце 1960-х годов IPSharp Associates и STSC, двумя ведущими компаниями по разделению времени APL. Файловая система и новые системные функции, такие как []FMT, форматирование отчетов, были частью усилий по повышению коммерческой эффективности APL\360. В то время предложение IBM, APL.SV, представляло TSIO в качестве аналога Native Files. Существовали дополнительные файловые системы для APL.SV, а также для будущих интерпретаторов IBM, таких как VSAPL и APL2.
Зачем вообще использовать файлы компонентов APL?
Тогда, если использовать Sharp или STSC, это было единственно доступным. Также файловая система сделала разработку очень простой. Возможно, это был лучший способ сохранить данные APL, когда альтернативой было использование собственных файлов. Если ваша система изначально работала с разделением времени или использовала некоторые ранние интерпретаторы STSC (Manugistics), она, вероятно, использовала файлы компонентов с самого начала. Доступ к DB2 из APL, сначала в форме AP126 для мэйнфреймов APL2 и Sharp APL, появился несколько позже, примерно в середине 1980-х годов.
Естественно, файловые системы компонентов между различными поставщиками, такие как рабочие пространства, были несовместимы.
Будет ли разумным вариантом перенести содержимое этих файлов компонентов в Native Files?
Это зависит от содержимого. Звучит так, как будто в этих числовых компонентах может быть собственная база данных. Это открывает гораздо больший вопрос миграции данных.