Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
Есть следующая задача: Необходимо спроектировать БД, хранящую и обрабатывающую некие документы. Документ имеет несколько полей. Информацию в документе всегда можно преобразовать к массиву строк "имя поля=значение(или NULL)". Документы приходят в различных форматах. Форматов много, они очень разные, могут добавляться и изменяться. Документов приходит много: до 100 000 в сутки. Необходимо хранить данные минимум за 3 месяца. Обработка подразумевает собой выдача документов клиентам по заранее заданному фильтру, перевод документа из одного формата в другой, ведение статистики и т.д. Клиенты строят фильтры по полям формата. Допустим "Отправитель='Москва' И срочность='ОЧЕНЬ СРОЧНО'". Для этого предполагается разбирать документы на поля и хранить их в разобранном виде. Возник вопрос как лучше сделать. Вариант 1. Для каждого формата сделать таблицу столбцы которой соответсвует полям формата. И раскладывать документы по таблицам. Вариант 2. Создать таблицу с полями: (document_id, format_id, field_name_id, field_value). Т.е. все складывать в одну таблицу с ссылками на формат и поле. Что лучше выбрать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2005, 19:49 |
|
||
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
Однозначно вариант 2, т.к. вариант 1 будете постоянно править и дополнять. Да и интерфейс будет более унифицированным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2005, 10:49 |
|
||
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
LSVОднозначно вариант 2, т.к. вариант 1 будете постоянно править и дополнять. Да и интерфейс будет более унифицированным.300 000 записей * 30 дней * 3 месяца получаем 10 млн. записей. Вы предлагаете умножить их еще на N параметров? И иметь базу данных, состоящую на 90% только из ключевых полей? По моему - вариант 1. При этом две таблцицы - одна реестр операций, вторая - детали. В таблицах набор полей разных типов. Одно и то же поле может иметь разный смыл для разного типа документов. Структура в этом случае стабильная. Ее не надо менять при появлении нового параметра в документе. Просто под этот параметр отводится одно из свободных полей подходящего типа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2005, 12:31 |
|
||
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
Практически тот же вопрос был про типы товаров ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2005, 13:15 |
|
||
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
2 PVP Совершенно верно ! Но, то, что Вы предложили и есть пожалуй Вариант 2, т.к. в Вар.1 у каждого типа документа своя уникальная таблица с уникальным назначением полей. А точнее, то это некий 3-й вариант. Не такой как предложил афтар топека :) :) Создавать на каждый тип отдельную таблицу заведома неверно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2005, 13:42 |
|
||
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
prof79Документы приходят в различных форматах. Форматов много, они очень разные, могут добавляться и изменяться. Что то мне не верится... Приходят в разных форматах или хранятся в разных форматах? Если это типизированные документы, то при закачке данных нужно приводить экземпляры к одному формату и хранить в одной таблице. Если это не типизированные типа приказов то в основной таблице хранятся обшие данные (номер, дата, автор, состояние...) а содержательная часть в блобе. LSVОднозначно вариант 2, т.к. вариант 1 будете постоянно править и дополнять. Да и интерфейс будет более унифицированным. А вообще истина обычно где-то рядом все что типизируемо лучше хранить в таблицах, все доп. данные которые зависят от экземпляров документов лучше хранить по "Вариант 2." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 09:37 |
|
||
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
У варианта 2 есть еще одно преимущество - он симметричен по отношению к именам параметров и их значениям. Можно легко спросить дайте мне все документы, где есть значение <1000, чтобы это не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 10:45 |
|
||
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
ModelRУ варианта 2 есть еще одно преимущество - он симметричен по отношению к именам параметров и их значениям. Можно легко спросить дайте мне все документы, где есть значение <1000, чтобы это не было. Универсальный тип хранения данных это строка, а с ней достаточно проблематично спросить "где есть значение <1000" без конвертации. Можно конечно разделять значения на 3 поля строка-сумма-дата, но тогда усложняется внесение данных. Плюс "вариант 2" имеет несколько неисправимых ограничений: а) Сложность организации отношений мастер-детейл, когда заносятся документы с перечнями б) Сложность построения типичных бизнес запросов типа выберите мне платежи, входящие, с даты.. по дату..., с суммой больше... где в описании платежа есть слово "комиссия" от клиента "ХХХ" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 12:52 |
|
||
|
вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
prof79 Если уж хотите "унификации" - то если у вас БД с поддержкой хранения xml документов с заранее известной схемой (есть xsd) - то воспользуйтесь ей. Это фактически вариант №1 но всю модификацию схемы хранения будет выполнять СУБД и для вас она будет прозрачной. А так - вариант 2 - это если мало времени или еще чего - в общем это будет не РБД ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 13:29 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=33151927&tid=1545777]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
138ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 469ms |
| 0 / 0 |
