По работе поставили задачу закончить СТП, начатое другим человеком.

Перед тем, как начать писать хочется представить себе возможные пути реализации, т.к., честно говоря, не нравится то, что сейчас в документе явно прослеживается не очень, по моему мнению, оптимальный вариант решения проблемы. Сразу замечу, что то, что у нас называется СТП – это некий гибрид ТЗ и ТП, то есть описываются и требования, и предлагаемые пути реализации. При этом разработчики могут по прочтению СТП сразу взяться за реализацию или написать свой ТП.

Ниже напишу еще свои соображения, а пока задача.

Суть задачи: Есть поток текстовых данных, разделенных на блоки. В каждом блоке требуется найти некий (или некие, если их несколько) идентификатор, вычислить (если требуется) контрольное значение для него и выдать в отдельный файл, возможно обработав перед этим.
Идентификатор: Последовательность символов в большинстве случаев описываемая в широких пределах.

Например, строка из арабских цифр длинной от 3 до 8 символов, ограниченная пробелами или началом(концом) строки.
В этом случае:
1. строка «Контракт3135» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
2. строка «145 гугл» верна, результат –  идентификатор «145».
2. строка «145568235 12-12-1985» неверна, результат –  отрицательный, т.е. идентификатор не найден.

Или идентификатор - строка, начинающаяся с открывающейся скобки “(” и заканчивающаяся закрывающейся скобкой “)”. При этом внутри скобок находятся три под-идентификатора, разделенные символом “/”. Первый под-идентификатор - строка из арабских цифр длинной от 3 до 8 символов. Второй под-идентификатор - строка из букв кириллического алфавита длинной от 10 до 20 символов. Третий под-идентификатор – дата (формата ДД-ММ-ГГ). Вернуть требуется первый под-идентификатор, при условии, что все идентификатор и под-идентификаторы распознаны корректно.
В этом случае:
1. строка «Привет (100/Маша/13-13-2010» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
2. строка «(100/Маша/13-10-2010» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
3. строка «(100/ /13-10-2010» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
4. строка «(100/ Сергей1/13-10-2010)» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
5. строка «(100/ Сергей/13-10-2010)» верна, результат – идентификатор “100”.

В перспективе идентификаторов может быть очень много и они могут быть очень разнообразными.

Предлагаемое решение, которое описано в СТП сейчас предлагает для каждого нового идентификатора писать свою процедуру разбора текста. При этом правила разбора пишутся прямо в коде процедуры и больше в системе сами по себе не существуют. 

Чем мне не нравится такое решение?
1. нужно каждый раз писать код для нового идентификатора.
2. нужно каждый раз писать код для нового идентификатора, если была допущена ошибка и процедура разбора работает неверно.
3. правила к идентификаторам существуют только в коде и их не видно пользователю.

Плюсы, которые я вижу:
1. процедуру можно написать какую угодно


Предлагаемое мной решение:
Реализовать справочник идентификаторов в котором они будут задаваться с помощью регулярных выражений POSIX (к примеру). Подключить к систему внешнюю библиотеку, реализующую парсер регулярных выражений и использовать ее (например, TextPipe).

Минусы моего подхода, которые я вижу:
1. нужно купить внешнюю библиотеку
2. пользователям потребуется разобраться с языком регулярных выражений (хотя можно передать эту функцию в службу сопровождения)

Плюсы:
1. не нужно писать код для каждого нового идентификатора
2. легко править описания для идентификаторов, если возникла такая возможность

Проблема моя вот в чем – как мне правильно поступить? Либо переписать СТП и оставить в нем только требования, либо запихнуть в него соображения по реализации, которые у меня не совпадают с тем, что в документе есть сейчас. Либо дописать СТП с тем подходом, который предлагается сейчас.

Поясню, почему не очень хочется оставлять только требования. В силу некоторой специфики, наши разработчики больше привыкли работать с БД, нежели с парсингом текстов и я на 90% уверен, что если оставить СТП так, как есть, никто не будет возражать. Напишут разбор на PL/SQL и все. Кроме того, обычно мы не используем внешних библиотек и еще и поэтому такая мысль может никому в голову не придти.

Если речь идет о PL/SQL, то есть Oracle, то там есть регулярные выражения (posix в полном объеме) и никакой библиотеки не нужно - это есть (REGEXP_LIKE Condition, REGEXP_* функции). А дальше - вопрос гибкости. Если есть подозрение, что regex может не покатить, например, из-за параметризации, то можно потребовать написать функцию. плюс сделать "по умолчанию" функцию с регулярными выражениями. А можно ограничиться регулярными выражениями.

а Perl выражения поддерживаются? POSIX не подходит для некоторых очень сложных выражений.

А вы посмотрите доку - что именно поддерживается. Это ж еще от версии плывет.

Дык на PL SQL напишите функцию, которая будет генерировать эти идентификаторы и дело в шляпе

Код: [Выделить]

create or replace function generate_id(type_id in varchar2) return varchar2 is
  Result varchar2(20);
begin
  case when  type_id='contract' then
    result:=type_id||sq_types_id.nextval;
  end case;
  return(Result);
end generate_id;
только сдается мне, что закладывать какую то идентификацию внутрь идентификатора (прошу прощения за тавтологию) это в корне неправильно. Идентификатор - это идентификатор. Он одназначно определяет запись или объект, никакой другой нагрузки он нести не должен. Ну а уж когда создаете объекты или чего вы там создаете - сделайте еще тип и по нему уже различайте типы объектов.

Короче задача не совсем ясна.

Дык на PL SQL напишите функцию, которая будет генерировать эти идентификаторы и дело в шляпе

Идентификаторы генерируем не мы, а клиенты.
В общем, напишу пока только требования и обсужу с архитекторами/разработчиками.

Идентификаторы генерируем не мы, а клиенты.
В общем, напишу пока только требования и обсужу с архитекторами/разработчиками.

Сядьте и внимательно разберитесь что-где генерируется и что вам нужно в итоге получить. На мой взгляд в вашей голове какая то каша.