Ответ в значительной степени зависит от характера различий между тысячами типов объектов и в какой степени и каким образом их можно классифицировать и, возможно, обобщать дальше. Discovery - это ключ к поддерживаемому дизайну в таких сценариях, как этот.
Ниже приведены некоторые возможные варианты сохранения, которые могут работать для вашего набора типов объектов. Придется подумать, чтобы рассмотреть плюсы и минусы каждого.
- Откройте скрытую структуру или шаблон в типах объектов, позволяя им быть разложен 1,2,3.
- Ознакомьтесь с категориями типов объектов, к которым можно применить (1).
- Сопоставьте несколько объектов с одним или меньшим набором таблиц или типов документов.
- Сопоставьте объекты друг с другом и определите мета-схему для обеспечения их доступности.
Независимо от того, является ли база данных реляционной или нет, как она структурирована, какие типы функций поиска доступны и как реализуются ключи, - это решение, которое должно быть принято после указанного выше обнаружения. Это лучшая практика.
Определение структуры данных таким образом, чтобы данные о сохранении, обслуживании и извлечении не могли получить требуемые характеристики в 500-страничной книге, что, безусловно, не является коротким ответом.
Изучение плюсов и минусов этих потенциальных вариантов было бы хорошим началом.Вы можете искать в Интернете эти философии персистентности по их именам и словам «база данных» или «настойчивость», чтобы увидеть описания и продукты поставщиков, которые соответствуют.
- Реляционной таблица
- Реляционная объект
- Табличные нереляционная
- Картирования (ключ и значение)
- Картирования (ключ и фиксированная полезная нагрузка записи)
- Документа (свободный текст)
- Иерархический
- График (сеть ребер, соединяющих вершины)
- многомерные (OLAP и другие)
Вы можете обнаружить, что причина у вас есть тысячи типов данных является то, что они соответствуют документу типы и единственное, что общее между ними является человеческим языком они написаны или возможно даже не это. Возможно, они являются произвольными языками, и в этом случае интернационализированные системы хранения документов - это варианты для изучения в первую очередь.
Вы можете обнаружить, что существует набор семантических правил, которые подтверждают 9 800 из ваших 10 000+ типов объектов, и в этом случае характеристика и спецификация правил могут привести к более гранулированной схеме хранения 4,5,6. Формализация семантической структуры в сочетании со структурным проектом разработки программного обеспечения (например, шаблон композитора или декоратора) может позволить грубое сокращение количества типов объектов.
Такой рефакторинг может быть полезен во времени и может ускорить ваш проект за небольшую часть времени.
После обнаружения дополнительной структуры вам необходимо будет определить, какой уровень нормализации имеет смысл для ваших требований к хранению, обновлению, извлечению и дискам.
Литература (по всему Интернету) по нормализации и денормализации поможет вам понять компромиссы между пространством, скоростью записи и скоростью чтения 7,8.9. Если каждый день хранится большой объем данных, характеристики ETL также будут значительно влиять на дизайн.
Выбор поставщика и продукта, вероятно, является последним, что вы сделаете в архитектурном отношении, прежде чем начинать разработку и реализацию низкоуровневого дизайна и тестирования. (Это еще одна проблема с таким количеством типов данных. Как вы будете тестировать 10 000 классов соответственно?)
Предоставление вам более узких рекомендаций, чем это было бы безответственным без дополнительной характеристики тысяч типов объектов и почему их так много.
Список литературы
[1] https://www.tutorialspoint.com/design_pattern/design_pattern_quick_guide.htm
[2] https://sourcemaking.com/design-patterns-and-tips
[3] https://sourcemaking.com/design_patterns/strategy
[4] https://www.cs.cmu.edu/~dunja/LinkKDD2004/Jure-Leskovec-LinkKDD-2004.pdf
[5] https://archive.org/details/Learning_Structure_and_Schemas_from_Documents
[6] https://www.researchgate.net/publication/265487498_Machine_Learning_for_Document_Structure_Recognition
[7] http://databases.about.com/od/specificproducts/a/Should-I-Normalize-My-Database.htm
[8] http://www.ovaistariq.net/199/databases-normalization-or-denormalization-which-is-the-better-technique/#.WLOlG_ErLRY
[9] https://fenix.tecnico.ulisboa.pt/downloadFile/3779571831168/SchemaTuning.ppt
Это распространенное заблуждение относительно реляционных баз данных, что таблицы представляют типы объектов, это на самом деле идея, полученная из сетевой модели данных. В соответствующих реляционных базах данных каждая таблица представляет собой тип факта, который может включать любое количество типов объектов в разных ролях. – reaanb
@reaanb, я согласен с тем, что объект 1-к-1 для сопоставления таблиц обычно не подходит. Модель сетевых данных является лишь одной из причин. Дизайн ленивого объекта и дизайн ER - это еще один. Помимо упомянутого вами типа типа фактов, существуют различные причины для поиска определенных уровней нормализации в схеме (основанные на практических ETL-тестах, проблемах синхронизации, скорости запросов и ресурсах). Дизайн объектов лучше всего управляется интеллектуальным дизайном сервисных или микросервисных интерфейсов. Структуры объектно-реляционного сопоставления намерены объединить два. –
Если кто-то должен был указывать источник и требовать, чтобы это было правдоподобным или официальным, чтобы ответить на этот вопрос, я был бы склонен отклонить источник как НЕ достоверный просто потому, что система с типами объектов 10K + является анти-шаблоном. Лучших практик не существует, кроме как найти способ не поддерживать так много типов объектов. В некоторых ответах есть некоторые рекомендации для этого. – FauChristian