То, о чем вы говорите, - это очень неудачный шаблон проектирования, называемый сериализацией: то есть объединение нескольких семантически разных частей данных в одну строку. В большинстве случаев это плохая идея, и практически во всех случаях лучше разделить данные на несколько полей или даже несколько таблиц. Используя сериализованные поля, вы найдете:
- Иметь намного, НАМНОГО более медленные запросы при запросе нескольких сериализованных подполей
- Сложные запросы для обновления нескольких частей одного и того же поля
- Чувство депрессии и отчаяния
Если бы мне пришлось иметь дело с такой базой данных, и я не мог бы изменить структуру базы данных, я бы, вероятно, в конечном итоге сделал много тяжелой работы в программном коде. Многие языки имеют лучшие (или, по крайней мере, более интуитивно понятные) инструменты обработки строк, чем SQL, и ваши преимущества в производительности от использования СУБД будут в лучшем случае незначительными при работе с сериализацией в любом случае.
Но если вам абсолютно необходимо сделать это в SQL, вы должны прочитать обработку строк в Postgres, расположенную здесь: http://www.postgresql.org/docs/9.1/static/functions-string.html
И вы правы, ваше решение, вероятно, будет включать регулярное выражение. То, как именно будет выглядеть это регулярное выражение, зависит от того, сколько сериализованных полей оно должно анализировать и как именно оно разграничено. В вашем примере похоже, что каждое подполе разделено парой пробелов и символом вертикальной черты между ними, и если это так, убедитесь, что вы либо создаете правила, позволяющие избежать этого разделителя по мере необходимости, либо убедитесь, что интерфейс никогда не передает разделитель в базу данных.
Конечно, если у вас есть такой контроль над интерфейсным приложением, вы можете дать сериализованным данным свои собственные поля.
person
Winfield Trail
schedule
08.08.2012