|
|
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
Пишу БД для хранения метаинформации, которая извлекается из файлов специального формата. БД используется для быстрого поиска нужной инфы по содержимому файлов. БД уже спроектирована и почти реализована. Начальство просит упростить БД следующим образом: 1. Отказаться от чёткой структуры БД и для каждого набора файлов заводить отдельные таблицы с одинаковой структурой (чтобы лучше понять, что это значит, представьте, что для каждого заказчика в БД заводятся свои таблицы типа customer_Газпром, customer_Лукойл). И так для всего набора таблиц. Основания начальства - так будет быстрее работать, т.к. отдельные таблицы будут меньшего размера, чем одна большая и поэтому будет быстрее работать. 2. Отказаться от нормализации (сейчас почти все таблицы в 3НФ). Т.е. вместо большого количества связанных таблиц сделать несколько таблиц с большим количеством столбцов. Основания - sql-запросы на выборку будут гораздо проще. Просто сегодня начальство увидело запрос с большим количеством join'ов и схватилось за голову :) Чем парировать запрос начальства? Объяснения, что это противоречит здравым принципам построения реляционных баз данных не принимаются. Надо что-нибудь посерьёзнее :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 19:25 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
> Автор: ArtDen > Пишу БД для хранения метаинформации, которая извлекается из файлов > специального формата. БД используется для быстрого поиска нужной инфы по > содержимому файлов. БД уже спроектирована и почти реализована. Начальство > просит упростить БД следующим образом: > 1. Отказаться от чёткой структуры БД и для каждого набора файлов > заводить отдельные таблицы с одинаковой структурой (чтобы лучше понять, > что это значит, представьте, что для каждого заказчика в БД заводятся свои > таблицы типа customer_Газпром, customer_Лукойл). И так для всего набора > таблиц. Основания начальства - так будет быстрее работать, т.к. отдельные > таблицы будут меньшего размера, чем одна большая и поэтому будет быстрее > работать. > 2. Отказаться от нормализации (сейчас почти все таблицы в 3НФ). Т.е. > вместо большого количества связанных таблиц сделать несколько таблиц с > большим количеством столбцов. Основания - sql-запросы на выборку будут > гораздо проще. Просто сегодня начальство увидело запрос с большим > количеством join'ов и схватилось за голову :) > Чем парировать запрос начальства? Объяснения, что это противоречит > здравым принципам построения реляционных баз данных не принимаются. Надо > что-нибудь посерьёзнее :) > От Вас по сути дела требуют написАть свою СУБД поверх основной. Чем парировать? Попросите в штат еще с десяток/сотню прогрммистов для изобретения своего лисапеда. :) Да, и еще учтите производительность. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:08 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDen, Если все таблицы одинаковой структуры, то первое требование не упростит, а усложнит БД. Вариант с одной таблицей медленнее не будет, достаточно проиндексировать ее по нужным полям, и все будет летать. Второе требование возможно не так и глупо, зависит от поставленной задачи. В определенных условиях проще не городить НФ, а слить данные в большую плоскую таблицу. Запросы делать на порядок проще. Насчет здравого смысла построения РБД - это верно лишь отчасти. Если мы строим систему, в которой например операторы вводят информацию, нам не обойтись без классификаторов, уникальных ключей и прочей аттрибутики 3НФ, потому как иначе вместо БД будет помойка. Если мы строим систему в которую информация копируется из внешней БД, то мы скорее всего уже не можем повлиять на качество исходных данных (они ведь УЖЕ сформированы). Поэтому и 3НФ не принесет никакой пользы. В любом случае - это лишь общие соображения, Вам на месте видней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:19 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
Senya_L От Вас по сути дела требуют написАть свою СУБД поверх основной. Чем парировать? Попросите в штат еще с десяток/сотню прогрммистов для изобретения своего лисапеда. :) Да, и еще учтите производительность. Да мне и самому переписать не сложно. Тем более, что оплата работы не сдельная, а повременная. Интересует именно мнение о таком способе проектирования БД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:28 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
> Автор: ArtDen > Да мне и самому переписать не сложно. Тем более, что оплата работы не > сдельная, а повременная. Интересует именно мнение о таком способе > проектирования БД > Ну Вы помните пословицу про "гоп"? ;) Хотя повременка вещь неплохая, но и терпение у начальства тоже не резиновое. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:34 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
GoffmanЕсли все таблицы одинаковой структуры, то первое требование не упростит, а усложнит БД. Вариант с одной таблицей медленнее не будет, достаточно проиндексировать ее по нужным полям, и все будет летать. Так давно всё проиндексировано и всё летает :) GoffmanВторое требование возможно не так и глупо, зависит от поставленной задачи. В определенных условиях проще не городить НФ, а слить данные в большую плоскую таблицу. Запросы делать на порядок проще. Природа исходных данных, которые надо хранить в БД - строго иерархическая. Набор связанных таблиц идеально подходит для их хранения. К тому-же меня удручает мысль, что придётся хранить кучу дублирующих данных, а если ещё и в эту большую таблицу влить справочники, то тогда вообще база расплывётся в размерах :) GoffmanНасчет здравого смысла построения РБД - это верно лишь отчасти. Не понял. Причём здесь РБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:35 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDen К тому-же меня удручает мысль, что придётся хранить кучу дублирующих данных, а если ещё и в эту большую таблицу влить справочники, то тогда вообще база расплывётся в размерах :) При сегодняшней цене гигабайта - это не такая уж проблема. ArtDen Природа исходных данных, которые надо хранить в БД - строго иерархическая. Набор связанных таблиц идеально подходит для их хранения. А что начальство - таких аргументов не принимает? :) ArtDen >>Насчет здравого смысла построения РБД - это верно лишь отчасти. Не понял. Причём здесь РБД? ArtDen Объяснения, что это противоречит здравым принципам построения реляционных баз данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:45 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
Еще, чтобы скрыть сложность физической модели, можно использовать VIEW или MATVIEW ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:48 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
GoffmanПри сегодняшней цене гигабайта - это не такая уж проблема. Т.е. когда на каждый гигабайт будет приходиться 10 гигабайт дублирующих данных - это хорошо? :) ArtDen Природа исходных данных, которые надо хранить в БД - строго иерархическая. Набор связанных таблиц идеально подходит для их хранения. GoffmanА что начальство - таких аргументов не принимает? :) Завтра на этот аргумент буду давить :) PS: Для меня РБД - это распределённые БД, а не иерархические ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:54 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDenPS: Для меня РБД - это распределённые БД, а не иерархические ;-) Не реляционные точнее. Поэтому и не въехал сразу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:55 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
> Чем парировать запрос начальства? Ничем. Баранам принципиально невозможно объяснить, что они бараны. Хотят и платят - получают ровно то, что хотят. Можно посмотреть на это с другой стороны: кривая база данных потребует постоянной работы, так что, например, увольнение Вам в обозримом будущем грозить не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:55 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
GoffmanЕще, чтобы скрыть сложность физической модели, можно использовать VIEW или MATVIEW Ну так они и используются (если ты имеешь ввиду вьюхи). По большей части для себя, т.к. удобно контролировать содержимое базы, используя простые запросы. Кстати, про MATVIEW я вообще не слышал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 20:58 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Можно посмотреть на это с другой стороны: кривая база данных потребует постоянной работы, так что, например, увольнение Вам в обозримом будущем грозить не будет. Думаю, тут дело совсем в другом. Шеф заботиться о том, чтобы после меня эту базу мог бы сопровождать другой человек. Похоже, на его взгляд, что чем БД проще (с точки зрения озвученных им просьб), тем будет проще для сопровождающего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 21:09 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
> Автор: ArtDen > guest_20040621 > Можно посмотреть на это с другой стороны: кривая база данных > потребует постоянной работы, так что, например, увольнение Вам в обозримом > будущем грозить не будет. > > Думаю, тут дело совсем в другом. Шеф заботиться о том, чтобы после > меня эту базу мог бы сопровождать другой человек. Похоже, на его взгляд, > что чем БД проще (с точки зрения озвученных им просьб), тем будет проще > для сопровождающего. > Нет, дело именно в том, что Вам говорит guest_20040621. С чего это база станет проще в сопровождении? С зоопарком таблиц? Я не очень понимаю, зачем нужно таблицы динамически создавать. Вам же указали SSIS, может свои средства импорта данных создать - разве ж кто возразит. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 21:35 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDen wrote: > 1. Отказаться от чёткой структуры БД и для каждого набора файлов > заводить отдельные таблицы с одинаковой структурой (чтобы лучше понять, > что это значит, представьте, что для каждого заказчика в БД заводятся > свои таблицы типа customer_Газпром, customer_Лукойл). И так для всего > набора таблиц. Основания начальства - так будет быстрее работать, т.к. > отдельные таблицы будут меньшего размера, чем одна большая и поэтому > будет быстрее работать. Бред, log(kN) = log(k) + log(N), т.е. вы теряете log(k), где k- количество ваших таблиц (компаний), т.е. константу. А вот как при этом вы будете писать программы, которые будут работать с этими таблицами - я не представляю. Для каждой свою что ли ? > 2. Отказаться от нормализации (сейчас почти все таблицы в 3НФ). Т.е. > вместо большого количества связанных таблиц сделать несколько таблиц с > большим количеством столбцов. Основания - sql-запросы на выборку будут > гораздо проще. Ага. А данных в этих таблицах будет больше. Значит обрабатывать их - дольше. Просто сегодня начальство увидело запрос с большим > количеством join'ов и схватилось за голову :) Ну, а на кой фиг вы их им показывали ? > Чем парировать запрос начальства? Объяснения, что это противоречит > здравым принципам построения реляционных баз данных не принимаются. Надо > что-нибудь посерьёзнее :) Я бы вообще ничего не объяснял. Т.е. начальство в принциме в такие дела соваться не должно. Это -- не его дело. Начальство задачу ставить должно, и сроки. А вот КАК вы это сделаете - уже ваше дело, и обязанность сделать это дело хорошо. Если всё же такое происходит - бегите из этой конторы. Объяснять людям, что они идиоты, занятие и неблагодарное, и бессмысленное. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2009, 23:41 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
MasterZivБред, log(kN) = log(k) + log(N), т.е. вы теряете log(k), где k- количество ваших таблиц (компаний), т.е. константу. А вот как при этом вы будете писать программы, которые будут работать с этими таблицами - я не представляю. Для каждой свою что ли ? SQL-запросы генерятся кодом. Если начальство прижмёт, то перейти на такую организацию таблиц будет довольно просто. MasterZivАга. А данных в этих таблицах будет больше. Значит обрабатывать их - дольше. Аргумент начальства - более простые запросы. MasterZivНу, а на кой фиг вы их им показывали ? В месадж-боксе выскочило исключение времени исполнения. И в нём - текст запроса :) А шеф рядом оказался :) MasterZivЯ бы вообще ничего не объяснял. Т.е. начальство в принциме в такие дела соваться не должно. Это -- не его дело. В какие дела должно вмешиваться начальство, решает само начальство :) Думаю, с этим никто не поспорит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 06:23 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDenОснования - sql-запросы на выборку будут гораздо проще Это чистый OLAP? ArtDenПросто сегодня начальство увидело запрос с большим количеством join'ов и схватилось за голову :) Хм. "Большим" - это 2, 5, 20, 255? Я бы на Вашем месте (ну или на месте начальства, если хотите) озаботился нормальным тестированием. Соответственно, количество join-ов не является священной коровой и если все работает (тесты пройдены) - то и до join-ов дело не доходит. ArtDenВ какие дела должно вмешиваться начальство, решает само начальство С этим можно и поспорить, кстати, но только аргументированно. Я как-то раз в подобной ситуации отспорил полномочия принятия решения единолично, а пытались давить и настаивать. Одного раза хватило, больше не лезут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 10:20 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDen пишет: > Аргумент начальства - более простые запросы. Оно что, понимает что-то в том, какие запросы простые, а какие сложные ? > В какие дела должно вмешиваться начальство, решает само начальство :) А где вам работать, решаете вы. С этим тоже никто не спорит. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 11:12 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
Разделяю точку зрения г-на MasterZiv. Мне было бы крайне дискомфортно работать на баранов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 12:57 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDenНу так они и используются (если ты имеешь ввиду вьюхи). По большей части для себя, т.к. удобно контролировать содержимое базы, используя простые запросы. Кстати, про MATVIEW я вообще не слышалКакая СУБД? Если приличная, то там кроме MAT VIEW должно быть и партиционтирование. Соответственно, вариант с несколькими таблицами - заменяется на партиционирование :) Про разные таблицы - покажите начальству, как будет выглядеть запрос по объединению данных из разных таблиц в один результат. На 10-20-30 таблицах UNION ALL работать будет не так и быстро, а запрос будет выглядеть развесело, с точки зрения разбирательства. Про 3НФ - система OLAP или OLTP ? Если OLAP, то от нормализации отказаться, возможно, стоит. Если OLTP - то не стоит, точно. Что конкретно джоинится в больших запросах - справочники или основные таблицы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 13:40 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
BelyКакая СУБД? СУБД (тока не смейтесь) - любая :) (это было самым первым требованием начальства). Сейчас отлажено и работает на Firebird и на Oracle. Планирую прикручивать MS SQL. Всё работает через голый ODBC и используется стандартный SQL. Особенности конкретных СУБД (автоинкрементные поля или работа с последовательностями) вынесены в специальные классы и используются по мере необходимости в зависимости от выбранной СУБД. Bely...Если приличная, то там кроме MAT VIEW должно быть и партиционтирование. Соответственно, вариант с несколькими таблицами - заменяется на партиционирование :) Структура БД очень простая. И данных ожидается не особо много. Думаю, безо всякого партиционтирования всё будет работать достаточно быстро. Сегодня подготовил тестовые данные (объём которых во много раз больше предполагаемых объёмов для нашей БД). На ночь поставлю импорт данных в БД. Утром будет ясно, насколько быстро всё работает. BelyПро 3НФ - система OLAP или OLTP ? Вот это - ХЗ. 3НФ по той системе, по которой учили в универе много лет назад :D Щас поищу в инете, чтобы ответить поточнее :) BelyЧто конкретно джоинится в больших запросах - справочники или основные таблицы? Всё что угодно. Запросы могут быть самые разнообразные (SQL-запросы генерятся в программе в зависимости от XML-команды клиента). Но чаще всего объединяются основные таблицы + чуть-чуть справочников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 14:07 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDenBelyПро 3НФ - система OLAP или OLTP ? Вот это - ХЗ. 3НФ по той системе, по которой учили в универе много лет назад :D Щас поищу в инете, чтобы ответить поточнее :)Чем конкретно должна заниматься система? Не с технической точки, а с точки зрения бизнес-пользователей. Для чего она? Регистрация проводок? Получение аналитических отчетов? ArtDenBelyЧто конкретно джоинится в больших запросах - справочники или основные таблицы? Всё что угодно. Запросы могут быть самые разнообразные (SQL-запросы генерятся в программе в зависимости от XML-команды клиента). Но чаще всего объединяются основные таблицы + чуть-чуть справочников.Пример запроса можно увидеть, чтобы оценить его сложность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 14:18 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
BelyДля чего она? Регистрация проводок? Для ускорения поиска нужной информации, которая хранится в файлах ArtDenПример запроса можно увидеть, чтобы оценить его сложность? Вот парочка свежих генерёных программой запросов: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 14:35 |
|
||
|
Просят упростить БД
|
|||
|---|---|---|---|
|
#18+
ArtDen, Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2009, 14:42 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35901515&tid=1543340]: |
0ms |
get settings: |
8ms |
get forum list: |
21ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
172ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 514ms |

| 0 / 0 |
