|
|
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
Приветствую всех! Я участвую в проектировании информационной системы. Суть: система получает информацию от различных поставщиков, обрабатывает ее, приводит в стандартизированный вид и заносит в БД. После того, как вся информация от всех поставщиков собрана и добавлена в БД, происходит ее сортировка, объединение и.т.д. Является ли нормальной практикой иметь отдельную таблицу для каждого источника? Таким образом, таблицы будут с одинаковыми сигнатурами, только названия отличаться. Или надо сразу заносить все в одну таблицу и в одно из полей записывать источник? Это противоречит теории построения БД? Например какой-нибудь N-ной нормальной форме? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2014, 01:15 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
Разделение сходных данных по куче таблиц должно иметь какую-то убедительную причину. Чаще всего такой выступает разница в структуре таблиц (источники не совпадают по информации и её форматом, удобно загрузить данные в виде как есть, а уж потом внутри базы очищать и править). Может выступать разница в бизнес-логике (структура в принципе одна, но алгоритмы обработки в каждом случае свои). Иногда могут быть более экзотические причины, скажем, связанные с правами доступа (кто какие источники может смотреть). Но если таких причин нет, то иметь дцатикратный геморрой только ради того, чтобы потом дополнительно "объединять".... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2014, 01:28 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
ValeOFYЯвляется ли нормальной практикой иметь отдельную таблицу для каждого источника? Нет. ValeOFY надо сразу заносить все в одну таблицу Только если сырые данные предполагается хранить наряду с обработанными. В противном случае их обработка может (и должна - в той мере в которой это возможно) производиться ещё до занесения в БД. Далее полусырые данные заносятся во временную таблицу, откуда уже и доводятся до готовности. ValeOFYв одно из полей записывать источник? Только если "сортировка, объединение и т.д." как-то от источника зависят. ValeOFYЭто противоречит теории построения БД? Это противоречит методологии KISS. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2014, 01:31 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
Всем спасибо, очень быстро и доходчиво! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2014, 01:33 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
ValeOFYЯвляется ли нормальной практикой иметь отдельную таблицу для каждого источника?softwarerРазделение сходных данных по куче таблиц должно иметь какую-то убедительную причину.Например, такой причиной может являться необходимость одновременной "неблокирующей" загрузки из разных источников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 13:16 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
UridianНапример, такой причиной может являться необходимость одновременной "неблокирующей" загрузки из разных источников. Это причина выбрать вменяемую СУБД, а не кривой дизайн. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 13:42 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovUridianНапример, такой причиной может являться необходимость одновременной "неблокирующей" загрузки из разных источников. Это причина выбрать вменяемую СУБД, а не кривой дизайн. Вы слишком категоричны. Вполне может быть, что таблицы разнесены по файловым группам :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 13:59 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
Arm79Вполне может быть, что таблицы разнесены по файловым группам :-)Совершенно без разницы куда они разнесены. Есть весьма ограниченное число задач, где поток данных, приходящий со скоростью на пределе железных возможностей, действительно необходимо хранить сколь-либо заметное время. И на таких задачах сидят люди, в подсказках форума не нуждающиеся. Типичные же задачи ТСов заключаются в приёме потока, обработке (агрегировании) и его дропе. Для таких задач показаны in-memory СУБД у которых нет проблем с блокировкой таблиц (за фактическим отсутствием таковых). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 14:34 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovСовершенно без разницы куда они разнесены. Есть весьма ограниченное число задач, где поток данных, приходящий со скоростью на пределе железных возможностей, действительно необходимо хранить сколь-либо заметное время. И на таких задачах сидят люди, в подсказках форума не нуждающиеся. Это не так. Бывают серьезные конторы, где из-за недостатка людей на проекты кидают молодежь. Так что вопросы на форуме от них могут быть. Что касается хранения, то например Siebel трижды перекидывает данные из одной таблицы в другую при импорте данных. Таким образом, загрузка нескольких миллионов записей растягивается на некомфортное время. В итоге, решение разносить заливку на разные таблицы при определенных условиях вполне имеет право нам жизнь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 14:44 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
Arm79Бывают серьезные конторы, где из-за недостатка людей на проекты кидают молодежь. По моим впечатлениям, расклад немного иной. Есть серьёзные проекты. Туда прямо или косвенно идут большие государственные деньги. За этими деньгами бегут "серьёзные конторы". А поскольку после того, как деньги освоены, что-то таки надо сдать, на проекты кидают молодёжь подешевле, воодушевлённую большими задачами. Как результат - http://izvestia.ru/news/579312 или прочее того же рода. Хорошие разработчики в это время сидят по нормальным конторам, которых к таким проектам не подпустят на пушечный выстрел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 14:55 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
softwarerArm79Бывают серьезные конторы, где из-за недостатка людей на проекты кидают молодежь. По моим впечатлениям, расклад немного иной. Есть серьёзные проекты. Туда прямо или косвенно идут большие государственные деньги. За этими деньгами бегут "серьёзные конторы". А поскольку после того, как деньги освоены, что-то таки надо сдать, на проекты кидают молодёжь подешевле, воодушевлённую большими задачами. Как результат - http://izvestia.ru/news/579312 или прочее того же рода. Хорошие разработчики в это время сидят по нормальным конторам, которых к таким проектам не подпустят на пушечный выстрел. Ну в общем, именно так :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 14:57 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
ValeOFY, в OK таблицы добавляешь ведущим полем источник данных и все в порядке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2014, 22:29 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
ValeOFY, на счёт того, чему это противоречит... это противоречит здравому смыслу. никаким НФ это не противоречит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2014, 22:32 |
|
||
|
Одинаковые таблицы в БД для разных источников информации. Плохое решение?
|
|||
|---|---|---|---|
|
#18+
ValeOFYТаким образом, таблицы будут с одинаковыми сигнатурами, только названия отличаться. Или надо сразу заносить все в одну таблицу и в одно из полей записывать источник? Это противоречит теории построения БД? В таком варианте добавление нового источника приведет к достаточно большой переработке структуры и механизмов: 1) добавление доп. таблицы 2) изменение всех процедур обработки для учета новой таблицы 3) изменение всех выборок из базы - добавление новой таблицы. 4) иные структурные доработки - индексы/триггеры и т.п. и т.д. Можно по дефолту всю обработку завязать на какое-нибудь представление, объединяющее "таблицы-источники" и т.д. и т.п. Но с этим проблем будет еще больше, чем преимуществ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2014, 12:35 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38808200&tid=1540733]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
164ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 279ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...