%[0123456789ABCDEF][0123456789ABCDEF][-:][0123456789ABCDEF][0123456789ABCDEF][-:][0123456789ABCDEF][0123456789ABCDEF][-:][0123456789ABCDEF][0123456789ABCDEF][-:][0123456789ABCDEF][0123456789ABCDEF][-:][0123456789ABCDEF][0123456789ABCDEF][-:][0123456789ABCDEF][0123456789ABCDEF]%
select val from (select val where val<10 order by val desc limit N) as t1
union all
select val from (select val where val>10 order by val asc limit M) as t2
Во времена DOS была такая СУБД FoxPro, а ранее dbase, paradox, clipper, clarion - это были в той или иной мере среды разработки/программирования со своими ЯП. Позднее - развились более другие и разные среды программирования, которые стали уметь универсально взаимодействовать с СУБД. Поэтому ныне при правильном подходе несвойственное СУБД делается не в ней и зачастую универсально: c/perl/php/phyton/c#/java/bash/powershell через промежуточный слой (фс) работают с файлом, разбирают его, а потом через другой промежуточный слой сливают результат в какую-нибудь любую СУБД. Притом сегодня в pg, завтра в mysql и т.д.
12 гиговый файл? Интерфейсы то будут сможете сделать , но как это будет ворочаться?А второй этап начнется когда надо будет эти 12 гигов пересинхронизировать с изменившимся первоисточником...
Сам обмен данными происходит по запросу?Например - да.
А что если в этом запросе 1000000 записей?Это много? Номенклатурных единиц у MB - порядка 1.5 миллионов. Но в наличии на складе - на порядок меньше, был оборот за последний месяц - на два порядка меньше. А отгруженных конкретному контрагенту - десятки-сотни-тысячи. А в конкретном случае заинтересовать может на какую сумму была отгрузка в прошлом месяце контрагенту X и тогда это одно число.
Впрочем в ситуациях когда в куске серийника фигурирует mac - для этой задачи это скорее на пользу пойдет...