Мое лучшее предположение состоит в том, что такая таблица используется для хранения произвольных данных (выведенных из других вспомогательных таблиц), которые не потребуют изменений схемы для хранения информации, которая «незапланирована» или еще не реализована в бизнес-логикеприложение.
Вопросы, которые я бы начал задавать (себе, любым программистам, администраторам баз данных, менеджерам проектов и т. д.):
- Были ли требования настолько абстрактными в то время, когданевозможно создать формальную схему с отношениями данных?(Плохо, плохо, ПЛОХО)
- Был ли разработчик базы данных ленивым или неопытным?
- Был ли программист ленивым или неопытным?(А еще лучше, был ли программист администратором базы данных?)
- Является ли надежность / доступность данных настолько чувствительной, что трудно регулярно вносить изменения в формальную схему?
- Имеет ли проектпрошли через множество людей до вас, которые просто унаследовали проблемы, и это решение взломать?(Хотя, может быть, оригинальный программист знал, куда он должен был пойти в конечном итоге ...)
Я думаю, что вы на самом деле пытаетесь достичь этого - «выполняет эту работу, или я должен изменить ее»?».Я был бы шокирован, если какие-либо запросы на чтение / поиск вообще оптимизированы, так как не может быть никаких индексов для такого произвольного хранения данных.Если приложение просто регистрирует информацию, это, вероятно, не так уж сложно, так как создатель, вероятно, просто еще не знал, как будут использоваться данные позже, и писал одноразовый апплет для циклического прохождения и создания.формальные объекты из данных были бы лучше, чем пытаться предположить все вначале.
Становясь немного более целенаправленным, сталкиваетесь ли вы с какими-либо узкими местами в своем процессе из-за этой конкретной таблицы, или вы обеспокоены толькоиз удивления?Если первое, я бы сразу понял, как это изменить.Если последнее, я бы потратил время на выяснение долгосрочных требований приложения.