ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Архитектура базы данных
10 сообщений из 10, страница 1 из 1
Архитектура базы данных
    #32032841
eugene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eugene
Участник
Мы разрабатываем структуру базы данных, в которой должны хранится следующие данные:

1. Постоянные данные, их порядка 30 000 элементов
2. Данные на каждый день по каждому из элементов.

Иными словами, количество постоянных данных – постоянно, а количество дневных данных каждый день увеличивается (т.е. <количество постоянных элементов>*<количество дней>)

Если реализовать данные на каждый день в виде одной таблицы, то через 365 дней там будет около 30 000 * 365 = 10 млн. записей. При это ширина записи – около 90 полей типа float/int. Какое здесь может понадобится железо?

Очевидно, что с такой таблицей будет очень трудно работать с точки зрения потребляемых аппаратных и временных ресурсов.

В системе может быть несколько пользователей (порядка 100 человек). Каждый пользователь в течении продолжительного промежутка времени работает с информацией только на две даты, и информация на остальные даты ему не нужна. Кроме того, эта информация практически не изменяется пользователями. Она заливается отдельной системой и предоставляется пользователям “как есть” ( As Is).

Как было бы лучше организовать архитектуру базы данных. И прочие рекомендации?
...
Рейтинг: 0 / 0
14.06.2002, 19:17:05
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32032844
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Участник
Насколько я понял в планируемой базе дневная запись будет иметь примерно такой вид.

WorkDate,Element_1_ID,Param1,...,Param90
...
WorkDate,Element_3000_ID ,Param1,...,Param90

1. Про то, какое конкретно нужно железо - не силен.
2. 10 млн. записей при правильном железе - не критично.
3. Проверьте еще раз, действительно ли все параметры представляют из себя уникальные значения, возможно некоторые из них являются расчетными по другим параметрам.
4. Аналогично, все ли элементы уникальны и не являются комбинациями других элементов?
5. Для всех ли элементов всегда задействуются все 90 параметров?
Если нет, то может быть имеет смысл сделать таблицу параметров?
Структура базы будет примерно такой:

Таблица Journal
WorkDate datetime,
ElementID int,
ParamID int,
ParamValue numeric (m,n)

Таблица Elements
ElementID int
ElementName varchar

Таблица Params
ParamID int
ParamName varchar

Возможно, записей будет больше, но зато каждая запись очень короткая. Numeric (m,n) заменит и int и float.

5. Часто бывает так, что работа, в основном, идет только с записями на определенную временную глубину, в производстве это обычно не более трех лет, в тоговле - двух. В таких случаях можно иметь два журнала - оперативный и архивный. По истечении разумного срока, "старые" данные из оперативного журнала переводятся в архивный.
...
Рейтинг: 0 / 0
14.06.2002, 20:44:48
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32032851
Фотография Слон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Слон
Участник
Во-первых, неизвестно, будет ли трудно работать или нет. Все очень сильно зависит от предназначения таблицы, насколько она транзакционная и т.д. А пока нет такой информации, совершенно невозможно толком ничего советовать. Кстати, выбора то нет, так или иначе прийдется заносить все данные в базу данных. А как расположить, в одну или много таблиц, это зависит от задачи и (не)раздельности данных.

--Слон
...
Рейтинг: 0 / 0
15.06.2002, 04:04:01
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32032956
Ольга
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ольга
Гость
1. Исследование предметной области (иногда занимает 6-12 месяцев).
2. Выделение справочной информации и создание справочников (т.е. const).
3. Выявление динамических данных, разбиение их на таблицы, создание связей со справочными таблицами.
4. Если информация идет из разных источников (например, отделов) и не пересекается - по разным таблицам.
5. Разделение доступа
6. Периодизация - сливание из БД в "хранилище"
7. Обоснование покупки/upgrade техники
8. Вопросы администрирования
9.
.
.
... Личный опыт - "сын ошибок" :-))


Удачи!
...
Рейтинг: 0 / 0
17.06.2002, 17:24:42
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32032975
AAron & Eugene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron & Eugene
Гость
2Olga

спасибо :) Мы знаем... Это как раз и есть проектирование бд :)


2Cat2
идея с такой таблицей Jornal интересна. Только мы пока не смогли придумать, как исходя из такой структуры попытаться вычислить средневзвешенные значения для многих ParameterID.
...
Рейтинг: 0 / 0
17.06.2002, 19:13:30
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32032985
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Участник
А какие примерно будут данные?
...
Рейтинг: 0 / 0
18.06.2002, 00:18:47
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32032989
Фотография Слон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Слон
Участник
Хммм... не уверен я, что решение типа журнала вообще что-то даст. Только представьте, какие будут планы запросов.... Это ж убьет напрочь сервер. Особенно при поисках записей по многим полям. В любом случае журнал такого рода приемлем только в случае, когда надо рожать проект, а неизвестно кол-во полей и их имена. А коли они все известны, то даже просто здоровая таблица с 90 полями и то - лучше.

ИМХО

Слон
...
Рейтинг: 0 / 0
18.06.2002, 01:02:46
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32033215
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
в случае со труктурой, предложенной Cat2
получаются некоторые проблемы:

1. Требуется выборка (1 строка) примерно следующего вида
Код: plaintext
1.
2.
3.
select sum(Value1 * Value2) / sum(Value2), sum(Value2), count(*) as Items, sum(Value15), avg(value7)
from Jornal
where (...)

в случае широкой таблицы - такое прокатывает на ура!
в случае узкой таблицы единственное, что я пока смог придумать см.ниже
Код: plaintext
1.
2.
3.
4.
5.
6.
select sum(J1.Value * J2.Value) / sum(J2.Value), sum(J2.Value), count(*) as Items, sum(J15.Value), avg(J7.value)
from Journal as J1
  inner join Journal as J2 on ...
  inner join Journal as J3 on ...
  inner ...
where (...)


в этом случае я думаю при объеме таблицы в несколько миллионов записей у оптимизатора снесет крышу, а следовательно и скорость работы будет невысока.

Есть ли у кого-нибудь мысли, как можно воспользоваться предложенным Cat2 вариантом?

Возможно есть другие способы решения, которые кто либо применял. Буду рад услышать какие либо мнения.
...
Рейтинг: 0 / 0
19.06.2002, 18:50:10
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32033221
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Участник
Решение через самосоединение единственное, состоящеее из одного запроса.
Но можно сначала развернуть вектор с нужными полями в плоскую таблицу, а потом по ней делать агрегаты.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select 
elementID,
sum(case when ParamID= 1  then ParamValue else  0  end) as Value1,
sum(case when ParamID= 2  then ParamValue else  0  end) as Value2
...
into #temp
from journal
where ...
group by elementID

select ... from #temp
...
Рейтинг: 0 / 0
19.06.2002, 20:01:21
| Ответить | Цитировать | Написать  
Архитектура базы данных
    #32033346
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
спасибо, Cat2.
до такого способа я что-то не дошел, хотя GROUP BY крутился в голове
...
Рейтинг: 0 / 0
20.06.2002, 15:41:04
| Ответить | Цитировать | Написать  
10 сообщений из 10, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Архитектура базы данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&gotonew=1&tid=1822263]:
 0ms
get settings:
 9ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 126ms
get topic data:
 8ms
get first new msg:
 5ms
get forum data:
 2ms
get page messages:
 43ms
get tp. blocked users:
 1ms
others: 229ms
total:  437ms
созд. / загр.: 437ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]