В одной задаче нужно сохранять и различать null и пустую строку в текстовом поле.
Подскажите, как это лучше сделать? Использовать в качестве пустой строки текст, который не будет встречаться в нормальных данных?
________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

chr(0)Во-вторых, типичные операции над отчеством
Речь не про отчество.
Оборудование принимает набор параметров, один из параметров отвечает за назначение адреса. Возможны три варианта:
1. Параметр в наборе отсутствует — назначается произвольный адрес из пула допустимых значений.
2. Параметру задано значение адреса — назначается выделенный адрес из пула зарезервированных значений.
3. Параметр в наборе присутствует, но значение не задано — назначается произвольный адрес и этот адрес в дальнейшем резервируется.
Пустая строка как раз под третий случай подходит.

1. Параметр (a2) в наборе отсутствует:

2. Параметр (a2) задан:

3. Параметр (a2) присутствует, но не задан:

А как тогда различить варианты 1 и 3?

Viewerостановились на следующем наборе символов удачной операции - [b]ye$_g00d_:)
Вот как раз этого я и хотел бы избежать, хотя в моем случае список нормальных значений формализован хорошо и можно использовать, например, минус "-".
Но и дополнительный столбец бы использовать не хотелось.
CLOB не очень удобен, но для задачи подходит.

Теория без практики мертва и бесплодна.

Есть в одной отрасли задача учета и управления ресурсами.
Для автоматизации этой задачи есть много различного софта, но нормального нет.
Как правило существующий софт заточен под бизнес-процессы конкретного предприятия (собственно он из этого предприятия и вырос) и на других предприятиях им пользоваться неудобно или невозможно.
Также есть некоторое количество более универсального софта, который теоретически может автоматизировать нужные процессы, но в как правило все равно требуется дорогая кастомная доработка и из-за того, что архитекторы/программисты далеки от отрасли, использовать этот софт неудобно, он требует в несколько раз больших трудозатрат, чем ведение учета вручную, на бумажках и в Excel. Обычно на тех предприятиях, которые сильно переросли учет вручную, подобный софт является самописным.
Пару лет назад сообщество энтузиастов начало разрабатывать опенсорсный продукт, который предназначен для немного других задач, но также позволяет вести учет и управление ресурсами. Сейчас его даже ряд предприятий использует в работе, хотя продукт пока сыроват и недоработан, но зато он архитектурно довольно качественно продуман.
Какое-то время назад у меня были мысли самому написать данный софт, я продумал его архитектуру и она была достаточно продуманной (это я уже задним числом вижу), универсальной и расширяемой. Но когда я начал было его реализовать, то понял, что лучше за это не браться, слишком много времени у меня эта задача будет забирать в ущерб основной деятельности.

А еще есть другой продукт, написанный на PHP с базой данных MySQL. Написан он ужасно во всех отношениях, на это хватает даже моих умеренных познаний, когда приходится просматривать код или структуру БД, мне просто глаза режет и приходится бороться с желанием начать все исправлять. В программном коде использованы все шаблоны из книги «как не нужно писать программы» (сборка SQL-запроса в строку без экранирования, перемешивание HTML с кодом и т.п.), а в БД вполне обычным будет join по CSV-данным в TEXT-поле.
Однако этот продукт работает, он удобен в использовании и практичен, так как разрабатывался с участием отраслевых специалистов.
И я его купил и пользуюсь им, несмотря на то, что есть гораздо более архитектурно правильные и качественно запрограммированные альтернативы.

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