Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Задача: Ежеминутно собираются данные по 10 тыс. параметрам, которые затем ложатся в архив. Что будет лучше: 1. “Длинная таблица” – 3 колонки (код, значение, дата-время) 2. “Широкая таблица” – 62 колонки (код, дата-время, 60 колонок значений за каждую минуту часа) Какая структура таблицы будет лучше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 11:58 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Как вам будет удобнее обрабатывать конечные результаты, так и делайте. Поскольку данные у Вас собираются и кладутся в БД через промежутки времени за которые СУБД запрос(ы) потенциально сможет обработать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 12:35 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
1ая будет лучше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 14:28 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Почему лучше? Дело в том, к нам пришел новый начальник, который навязывает свою структуру таблиц (а у нас уже есть готовая, рабочая структура - первый вариант). И ему нужны весомые аргументы, почему его структура (второй вариант) неправильна, а наша правильна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 15:00 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Ну в вашей ситуации было бы правильней если бы свои агрументы привел как раз он.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 15:31 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Самый главный аргумент - он начальник :-))) Второй - не нравяться ему таблицы в миллионы записей (секционированная таблица с локальным индексом) Вот в общем-то и все его аргументы. Наш аргумент, что с таблицей по первому варианту проще работать, он просто не воспринимает. Может посоветуете что-нибудь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 15:51 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
А что тут посоветуешь: в вашем случае как раз, по классике, можно денормализовывать. Работать с таблицей будет действительно сложнее. Зато таблица действительно будет короче в длину. Вот и весь сказ. Единственный аргумент - то, что ваша таблица уже работает, а вариант начальника еще нужно разрабатывать ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 16:05 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Вообще первый вариант более верный. Второй же предпочитают люди старой закалки. Тоже самое было у нас с бухгалтерией, когда начальство говорило, что все проводки надо хранить в одной таблице, а не в нескольких :-). Первый подход более свойственен для реляционной СУБД. А объяснить попытайтесь тем, что вдруг придется менять количество выбираемых значений, то придется переписывать программу на извлечение большего числа столбцов из таблицы, а это лишнияя трата средств, нервов и времени. В то время как при первом подходе, просто увеличится количество записей, которые программа обработает и без переписывания (если она так спроектирована :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 16:07 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
А у вас у самих нет аргументов??? Надо почитать нормальные формы и правила построения РБД, и тогда все ясно станет и аргументы найдутся. Начало для размышдений дал pavelch . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 18:25 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
"И ему нужны весомые аргументы" Аргумент против структуры начальника - если шаг по времени вдруг изменится (понадобится обрабатывать данные на поминутно, к примеру, а каждые 20 сек), придется менять структуру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 21:46 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
авторНаш аргумент, что с таблицей по первому варианту проще работать, он просто не воспринимает. опишите ему разницу по времени разработки приложения в 1 и в 2-ом случае. Если она существенна - ваше дело в шляпе :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2004, 22:02 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Большое спасибо за советы, будем читать доки :) Киньте, пожалуйста, ссылки на доки по нормальным формам и правилам построения реляционной БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2004, 07:54 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
На самом деле вопрос в том какие запросы чаще используются клиентским приложением. Например, если значение одного параметра по времени не является значимой величиной, а имеет смысл только совокупность всех значений - то второй вариант верный. Если же нужно получать зависимость одного параметра от времени - то первый вариант будет работать быстрее: чтение N записей широкой таблицы приведет к чтению бОльшего кол-ва секторов на диске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2004, 09:37 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
2classn 10 тыс инсертов в минуту, ИМХО дешевле 10 тыс апдейтов. А основной напряг тут будет как раз на добавлении инфы. Опять же ИМХО. Кроме того непонятно по второму варианту. Для 1 часа есть поля по минутам. А для последующих часов? Новые записи? Или старые переписывать? Если первое, то запаришься выбирать например с 12.36 до 18.43 по второму варианту. Какой срок предполагается хранить инфу, ибо в год набегают сумащедшие цифры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2004, 10:51 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Как раз с insert проблемм нет, что insert, что update идет одно и тоже время. Для последующих часов создаются новые записи. Насчет выборки данных по второму варианту в пределах одного часа - действительно запаришься составлять запрос. Мы об этом и говорим начальнику. А он... в общем гад он :-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2004, 12:52 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
вообще - спорить нечего ваша структура на 100% адекватна . То что предлогает начальник - это своего рода упаковка (правда будет ли выигрыш - это еще надо проверить) - если он хочет - пусть еще предложит хранить значения не в 60 полях а в строке char(60) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2004, 13:20 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
Спасибо 'funikovyuri' на добром слове. :-)) А вообще насчет char(60) - были такие попытки, отбились :-)) Все дело в том, что у нас есть старая система, которая работает на FoxPro-dbf, отсюда все проблемы - начальник хочет просто перетащить базу в Oracle с наименьшими переделками ("ведь там все уже 10 лет работает"-в общем-то тоже аргумент), но эта система создавалась 10 лет назад и с точки зрения построения РБД структура у старой базы жутко кривущая (у меня иногда возникает вопрос "и почему-же это все еще работает:-)). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2004, 15:01 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
можно для очистки совести предложить еще такую структуру период (период_id, период_дата) измеренные_данные (id,период_id, ну и поля с параметрами) при этом период_дата - это дата периода в без с точностью до минут id - это только секунды и миллисекунды (для периодов длиной в час) + можно подогнать требуемый период - здесь он 1 час - можно, например, 1 сутки Таким образом, вы исключаете некоторую избыточность вашего варианта - но в отличие от варианта начальника - сохраняете 100% реляционность ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2004, 16:45 |
|
||
|
Проектирование БД. Что лучше?
|
|||
|---|---|---|---|
|
#18+
мне вот интересно, как ваш начальник собирается отчет делать по периуду времяни? Особенно с точностью до минут? причем время задает разумеется пользователь.... Oracle и такое предлагать.... Мне кажется такого начальника нужно сильно пнуть под зад.... Тем более нового.... пусть прежде пообвыкнится, прежде чем всякую лажу пихать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2004, 05:50 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32411091&tid=1546616]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
67ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
| others: | 16ms |
| total: | 202ms |

| 0 / 0 |
