последний ответ можно трактовать так — автор не осилил работу со стандартной струтурой ;) если у вас есть проблемы с тем, как корректно заполненные данные отображать — это или не правильный инструмент или недостаток навыков ;) более того вы опять пришли к пункту что храненение данных вам диктует отображение и редактирование ;) перестаньте это смешивать в 1 кучу, используйте mvc паттерн или что-то подобное и будет вам щастье. если нет возможности или желания сделать все красиво — вас здесь никто не заставляет, но не надо свои ограничения (вероятнее всего придуманные) излагать как общую проблему ;) у вас стандартная задача(хранение) и никакой нестандартный интерфейс(даже если он и в правду нестандартный ;) не отменит того, что хранить данные можно гибко.
ваши рассуждения про sql заставляют подумать что вы боитесь его использовать ;) не бойтесь — это не больно ;) при работе с базой его все равно придется юзать и если заспрос сложнее обычного селекта вызывает приступ паники, то проблема все равно не имеет отношения к архитектуре. более того «Для обычного поиска по названию товара» HAVING не нужен… в sql еще много интересных слов ;) а поскольку имя товара предложено хранить в читаемом виде в таблице goods — даже боюсь представить, откуда проблемы с поиском ;)
в общем, на вопрос вам ответили, а нежеление/неумение использовать нормальные варианты не надо оправдывать надуманными проблемами ;) если лень — то хотя бы себе надо признатся — да — лень ;) остальные и так догадаются ;)
ну и еще в догонку… если говорить о пректировании БД «по взрослому», стоит, хотя бы минимально освоить нечто вроде Sybase PowerDesigner(я его выбрал для себя из 5-6 опробованных вариантов). как и любая хрень для UML-моделирования, позволяет оценить некоторые решения ДО реализации(да и сэмплы там приличные есть — будет что посмотреть). и если UML для собственно программ, в продакшене себя оправдал только для обсуждений(его оказалось нереально суппортить синхронно с кодом), то для БД мне иногда удавалось рефакторинг, или даже почти всю разработку, делать через PowerDesigner :) ну а reverse engineering существующих баз позволяет наглядно увидеть с каким безобразием предстоит работать ;)
все таки повторюсь ;) читайте про нормализацию, потому как ваши рассуждения полях и таблицах, кхм, несколько наивны ;) и да — отделить данные от бизнес логики и отображения — достижимая без всякой магии реальность ;) опыт, вдумчивое чтение манов и попытки следовать «хорошему стилю» дают результаты :) с другой стороны, если что-то работает с «не идеальной» архитектурой и уже решает ваши задачи — то лучше так, чем ненаписанная «идеальная» система ;) в общем, удачи :)
эх, молодежжж… ну не надо про ООП в делфи и билдере — там все как у всех а кое-что даже лучше ;) Проблема в том, что ООП нормально использует только лучшая, дай бог, половина программеров в ЛЮБОМ ЯП :) проблема говно кода актуальна для всем языков, просто на некоторых(Python, Ruby) его еще не столько наплодили ;)
по делу — когда-то писал заметку о том как можно в делфях и конфетку съесть и не наговнокодить ;)
была мысль для хабра переписать, но не собрался, так что смотреть тут — pyatochkin.blogspot.com/2010/10/delphi-mvc-pattern.html
ваши рассуждения про sql заставляют подумать что вы боитесь его использовать ;) не бойтесь — это не больно ;) при работе с базой его все равно придется юзать и если заспрос сложнее обычного селекта вызывает приступ паники, то проблема все равно не имеет отношения к архитектуре. более того «Для обычного поиска по названию товара» HAVING не нужен… в sql еще много интересных слов ;) а поскольку имя товара предложено хранить в читаемом виде в таблице goods — даже боюсь представить, откуда проблемы с поиском ;)
в общем, на вопрос вам ответили, а нежеление/неумение использовать нормальные варианты не надо оправдывать надуманными проблемами ;) если лень — то хотя бы себе надо признатся — да — лень ;) остальные и так догадаются ;)
P.S. я всё здеся, больше не приду