Цитата:
Хорошо, вот задача (для особо понятливых) к справочнику Номенклатурные единицы нужно прикрутить подробное описание, причем представте что именно описание идентифицирует для пользователей ту или иную единицу, без описания он вообще не понимает что это за номенклатура. вот реальный пример, а простите каждый раз что бы посмотреть или отредактировать описание тыкать на документоооборот - не удобно и долго и там нет возможности сохранить измененный текст.
С этого и надо было начинать.
Я резко против такого подхода.
Вы же нарушаете принципы СУБД вы в ОДНО ПОЛЕ запихиваете ЦЕЛЫЙ НАБОР свойств / характеристик товара, без мысли о том времени когда пользовтелям захочется искать по этим полям, сортировать по ним по отдельности и т.п. (собственно про это уже сказали).
Задумайтесь - форматированный текст имеет смысл только тогда когда отдельные элементы текста, несут в себе разнородную информацию, следовательно их удобно визуально отделять друг от друга форматированием - один род информации от другого (как например Заголовок, Тех-характеристики, Размеры, Цена и т.п.) - только в этом случае форматированный текст может пользователям быть полезен.
Но если вы забьете все эти характеристики в одно BLOB-поле таблицы, внутри которого эти секции будут выделяться друг от друга красивым форматированием, вы произведете мощную денормализацию БД и подложите себе свинью да месяцы, если не годы вперед.
НЕПРАВИЛЬНО!
Правильным подходом тут является примерно следующее:
Выделить те наборы свойств, которые пользователям нужно видеть в форматированном тексте, завести эти поля в таблице, создать закладку или несколько для их отображения и правки стандартным для аксапты способом.
А "красивую, печатную формочку" завести как отдельную закладку в режиме read-only, в которую при активации будут эти свойства переносится ПО ШАБЛОНУ.
Подход во первых даёт вам все преимещества использования БД (фильтрация, поиск и т.д.), во вторых позволит на лету менять шаблон форматированной формы не сталкиваясь ни с какими проблемами.