Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
> опасения по поводу нежелательности(непонятно почему?) хранить большие обекты в самой базе Нет опасений. И нежелательности нет. И речь шла не об объектах, а именно о файлах. Лучший способ хранения файлов - файловая система. По определению. > а не в файлах, не находят подтверждения. Хм... цифры и тесты - в студию. > Все работает отлично, это по факту...Пока правда, только под IB Еще раз: хранить файлы в базе данных - это ошибка. Хотите ходить по граблям - ходите, лично мне это проблем не создает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 23:40 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Я бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:41 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Дык все слышали о граблях, но никто не видел :)) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:45 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
И хотя тема топика уже давно отошла от того, с чего она начиналась, все-таки хотелось бы немножко к ней вернуться. Тут уже упоминался стандарт JDO. Правда какого-то ответа я так и не нашел. Поэтому хотел бы задать такой вопрос. Существует такая группа ODMG, которая и занимается стандартизацией хранения объектов, в т.ч. и отображением их на реляционные БД. Помимо наработок для Java существуют и достаточно четко формализованные принципы и для других языков (например, C++). Как уже было отмечено, существует и большой выбор продуктов O/R мэппинга (Versant Open Access, Solarmetric KODO, ...). Упоминавшиеся в разговоре Object Factory тоже можно связать с реляционными хранилищами (например, FastObjects SQL Object Factory). Разумеется теоретическое обсуждение оптимальных способов проектирования и разработки имеет ценность и само по себе. Но насколько вообще разумно делать продукт, который (насколько я понял) во многом (понял что не во всем) повторяет функциональность давно присутствующих на рынке продуктов известных компаний? Не будет ли более рациональным опираться на существующие в мире наработки с тем, чтобы пойти дальше? Именно в этом случае продукт может привлечь значительный интерес и иметь успех. ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 18:11 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
> Не будет ли более рациональным опираться на существующие в мире наработки с > тем, чтобы пойти дальше? Именно в этом случае продукт может привлечь > значительный интерес и иметь успех. Если говорить о маппинге как таковом - есть не только наработки, но и продакшн решения (hibernate, например). Проблема в том, что imho задача много шире маппинга. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 19:18 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло.. "Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 01:53 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
vybegallo"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)"Вымывание" это конечно здорово, но только при неграмотном использовании.... конечно если блобы дергаются лишь для того чтоб в гриде их отобразить, то тогда да.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 09:20 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
vybegallo Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло.. "Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса) Хе-хе...Я бы пожалуй с вами и согласился бы, если бы не мой собственный эксперимент! Он не подтверждает вашу теорию. Эксперименты с mssql и opacle впереди, есть у меня ощущение (не могу пока этого доказать), что раскрученные марки Oracle и Mssql в данном конкретном аспекте окажутся позади... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 14:52 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Dik76 vybegallo"Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса)"Вымывание" это конечно здорово, но только при неграмотном использовании.... конечно если блобы дергаются лишь для того чтоб в гриде их отобразить, то тогда да.. Для борьбы с "вымыванием" Информикс придумал хранение и использование блобов отдельно от остальных данных (это, правда, ведет к отдельному геморрою) - но я что-то никак не придумаю, каким образом "грамотное" их использование (не только для "отображения в гридах - это, кстати, тут при чем ?) поможет вам сохранить индексные страницы в буферах. Пример приведете, а то я, может, чего не понимаю в internals ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 17:00 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Programmer_Ortodox vybegallo Programmer_OrtodoxЯ бы и сам не прочь изучить "грабельные" аспекты вопроса, связанного с использованием BLOB, но пока никакого безобразия ни откуда не вылезло.. "Вымывание" более полезных данных (индексы, данные из строки) данными блобов из буферов СУБД. Дополнительная работа, связанная с сохранением блобов в физических и логических логах. Как следствие - падение производительности сервера и всех приложений на нем. (если мы, конечно, имеем в виду промышленные СУБД типа Оракла, ДБ2 или Информикса) Хе-хе...Я бы пожалуй с вами и согласился бы, если бы не мой собственный эксперимент! Он не подтверждает вашу теорию. Эксперименты с mssql и opacle впереди, есть у меня ощущение (не могу пока этого доказать), что раскрученные марки Oracle и Mssql в данном конкретном аспекте окажутся позади... И в чем заключался ваш эпохальный эксперимент, позвольте поинтересоваться ? Вы меряли суммарную производительность сервера ? отмечали изменения hit ratio для чтения и записи до и после использования блобов ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 17:04 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Programmer_Ortodox funikovyuriТ.е. можно вообще забыть про вопросы проектирования структуры базы, имея эту, универсальную и неизменную. А эту структуру строят изходя из каких знаний/соображений? На сегодня это пока так: Подключаемся с sql-серверу, выполняем готовый sql-скрипт. Все, стуктура готова. Для наполнения/реорганизации используется клиентская программа, получается, что это как бы админская утилита. Дальше можно разрабатывать разнообразные приложения, которые при работе с базой пользуются одной и той же структурой, получается такое связующее эти приложения звено. По моему мнению это очень хорошо. Блин! Мужик, верной дорогой идешь! На протяжении многих лет стараюсь сделать то же самое. Давай объединяться! Вкратце: Пользователю важен результат. Не важно как, не важно с помощью чего. Ему важен результат. Все-равно как. Пользователью нужно готовое решение. Разработчику бизнес-правил также не важно как хранятся данные, где хранятся, в каком виде. Ему важны правила обработки данных. Логические связи м/у данными. Разработчику нужна платформа. Разработчику нужна универсальная платформа. Универсальная насколько это возможно. Созданное Programmer_Ortodox хранилище данных подходит для этих целей. Такое хранилище - нижний слой. Теперь нужно сделать процедуры добавления/обновления/удаления, истории (версий документов) Сделать версии процедур. Т.е. историю программ обрабатывающих данные. История - это отдельный разговор... И все-таки без описания объектов, их связей (какие объекты куда разрешается вкладывать), их свойств (вязкость можно применить только к жидкостям...) не обойтись. Нужны метаданные. Возможно эти метаданные будут в виде бизнес-правил. Надо подумать... И правильно, что не придерживаешься никакой парадигмы! Это новое. Такого еще не было. И готового решения нет. Напиши мне: ICQ 230979104. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2005, 10:25 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
> Нужны метаданные. > Возможно эти метаданные будут в виде бизнес-правил. > Надо подумать... Это бред, вызванный новогодней алкогольной интоксикацией? > И правильно, что не придерживаешься никакой парадигмы! > Это новое. Такого еще не было. И готового решения нет. Готового решения чего? Метаданных в виде бизнес-правил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2005, 13:34 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Нужны метаданные. > Возможно эти метаданные будут в виде бизнес-правил. > Надо подумать... Это бред, вызванный новогодней алкогольной интоксикацией? > И правильно, что не придерживаешься никакой парадигмы! > Это новое. Такого еще не было. И готового решения нет. Готового решения чего? Метаданных в виде бизнес-правил? Парирую Ваши нападки молчанием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2005, 14:40 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
adisk Блин! Мужик, верной дорогой идешь! На протяжении многих лет стараюсь сделать то же самое. Давай объединяться! Вкратце: Пользователю важен результат. Не важно как, не важно с помощью чего. Ему важен результат. Все-равно как. Пользователью нужно готовое решение. Разработчику бизнес-правил также не важно как хранятся данные, где хранятся, в каком виде. Ему важны правила обработки данных. Логические связи м/у данными. Разработчику нужна платформа. Разработчику нужна универсальная платформа. Универсальная насколько это возможно. Созданное Programmer_Ortodox хранилище данных подходит для этих целей. Такое хранилище - нижний слой. Теперь нужно сделать процедуры добавления/обновления/удаления, истории (версий документов) Сделать версии процедур. Т.е. историю программ обрабатывающих данные. История - это отдельный разговор... И все-таки без описания объектов, их связей (какие объекты куда разрешается вкладывать), их свойств (вязкость можно применить только к жидкостям...) не обойтись. Нужны метаданные. Возможно эти метаданные будут в виде бизнес-правил. Надо подумать... И правильно, что не придерживаешься никакой парадигмы! Это новое. Такого еще не было. И готового решения нет. Во! Наконец-то была озвучена основная задача девелопмента! И вариант решения есть: Братцы, я с августа месяца активно работаю с Bold for Delphi / Bold for C++. Совершенно чумовой подход – девелопер разрабатывает объектную модель приложения, на основе ее генерирует базу (Фактически, база данных становится объектной и прозрачной для разработчика.) и строит приложение (обеспечивая автоматизированный переход от модели на UML к функциональному коду). Вплоть до GUI. Поддерживаются совершенно различные варианты – 1 – 2 – 3 – 4 – 5 – … - звенка. Поддерживаются самые экзотические связи между данными. Поддерживается версионность данных (документов). Поддерживается версионность модели (переход от одной модели к другой). Поддерживается версионность структуры базы (переход от одной структуры к другой). Чумовой GUI (контекстно – чувствительный к контексту drag-n-drop, например), полная синхронизация состояния объектного пространства и его визуального представления (никаких датасетов с их рефрешами и проч). Реализация синхронизации между клиентами системы (например, это можно выразить в возможности совместного редактирования данных с синхронным отображением сделанных удаленными клиентами изменений). Реализация Легко создаются новые контролы. Превосходная поддержка third – party компаниями – технологии, компоненты, расширения… Реальное разработки проекта сокращается десятикратно. Дальнейшее развитие – для дот – Net – ECO называется. Обеспечивает единый архитектурный подход для различных разрабатываемых задач. Позволяет без особых трудозатрат реализовать программирование систем со сложными логическими взаимосвязями между объектами, практически не реализуемое или очень трудно реализуемое при использовании традиционных методов проектирования/разработки. Поглядите здесь , чтобы не повторяться. Подводные камни – да, есть. Пару синяков набил. Но уже научился обходить. Да, отмечу, что с первых шагов система производит весьма несерьезное впечатление своей простотой. … Но потом! Посмотрите в сторону Bold, не поздно еще – 2005 год только начался! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2005, 03:34 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Перед всеми неоднократно вставала задача: Нужно описать новый предмет (товар, материал, услугу,...). Предмет имеет свои, свойственные только ему признаки-атбриуты (свойства). Как хранить описания предмета? Добавляем новый справочник! С добавлением справочника необходимо: 1) сделать форму для ввода данных 2) процедуры проверки правильности вводимых данных 3) форму редактирования 4) форму выбора строки из справочника 5) написать процедуру добавления данных 6) процедуру модификации 7) процедуру удаления 8) процедуры-тригеры проверки целостности данных в базе 9) процедуры для обеспечения истории справочника 10) написать/изменить процедуры для отчетов, где будет нужен справочник 11) изменить/написать сами отчеты 12) Обязательно напишите мне, что еще нужно сделать. Все предложения будут учтены. Неоднократно добавляя справочники, документы, создавая процедуры, формы, отчеты, мы замечаем, что действия однообразны (подобны). Однообразие и лень подталкивает нашу творческую натуру занятся упрощением работы. Ее совершенствованием. Через это проходят все программисты и разработчики БД. Все задумываются над обобщением данных и над созданием чего-то универсального... Разные люди справляются по-разному: 1. усидчивые - старательно пишут процедуры, рисуют формы, отчеты. на это требуется время. аккуратность. увеличивается объем кода и соответственно процент ошибок. 2. хитрые - копируют куски кода, копируют формы, отчеты. 90% работы сводится к поиску и замене. все происходит быстро. вроде бы приемлемо для всех. Человек работает, выполняет работу в срок... 3. смекалистые - (и самые хитрые) накопировавшись вдоволь, обобщают данные, делают шаблоны для процедур, форм, отчетов. Создают классы. (возможно, здесь и рождается ООП) Создают генераторы процедур, форм, отчетов. Все происходит быстро и удовлетворяет всех, но... Достигнув третей стадии програмеры задумываются: как сделать так, чтобы ничего не делать? Нельзя ли написать единое хранилище для всех данных? Создать единые формы ввода? Написать универсальный генератор? Глядя на файловую систему, понимаем, что единое хранилище возможно. Кстати, что такое файл? Это те же данные... Данные с именем. И комбинация ПУТЬ+ИМЯ - это уникальный код. Не хватает возможности быстро извлекать данные по разным признакам. Решается созданием индексов. Не хватает на файловой системе и самих признаков (атрибутов, свойств, описывающих данные) Кстати, WinFS, разрабатываемая MicroSoft файловая система, позволяет добавлять файлам различные атрибуты и искать по атрибутам. Это не в коем случае не реклама WinFS. MicroSoft как всегда сделает все очень медленным, требующим Пентиум 10 и Терабайт памяти. За примерами далеко ходить не надо ;) Вернемся к нам, к простым смертным. Дальнейшие пути развития: Путь 1. Написать единый генератор, использующий метаданные. Генерировать структуры базы данных, процедуры, формы, отчеты (конечно, 90% отчетов надо будет рисовать ;)) Путь 2. Создать единое хранилище, общие для всех процедуры, формы, отчеты. Как будем действовать? adisk --- PS: Мы все делаем одно дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2005, 13:21 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 15:37 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 15:41 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 15:42 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 15:45 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 16:15 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
О хранении файлов в БД: Можно хранить. Бесспорно. Только как быть с большими файлами, с музыкой, с фильмами? Возьмем для примера фильм. Получается надо выкачать из базы файл размеров 650 М, куда-то его сохранить... Или же делать из базы файловую систему с возможностью передвижения по данным (fseek()). База в свою очередь будет работать с файловой системой, где будет выполнять опять же fseek()... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 16:32 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
To adisk : Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 17:38 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
VybegalloTo adisk : Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно... Что ж. Возможно еще не дорос. Прекрасно осознаю, что будет падение производительности. Будет ли оно столь ощутимым? Думаю нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 18:06 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
adisk VybegalloTo adisk : Это ваше "универсальное хранилище" придумывается каждым программистом баз даных на определенном этапе профессионального роста. Позже приходит понимание, что выигрыщ в простоте проектирования не стоит сооруженного на свою голову геморроя с запросами. А потом приходит заказчик и закатывает истерику, что все работает недопустимо медленно... Что ж. Возможно еще не дорос. Прекрасно осознаю, что будет падение производительности. Будет ли оно столь ощутимым? Думаю нет. Ну давайте я помогу дорасти. Дано : таблица customers, 100 000 записей customer_id int customer_desc char(50) Таблица orders, 1 000 000 записей order_id int customer_id int order_desc char(50) order_cost decimal (9,2) order_date date order_flag char(1) Требуется : найти сумму отгруженных договоров (order_flag="Y") с 1.1.2004 по 31.12.04 по каждому покупателю и описание покупателя. select customer_id, customer_desc , sum(order_cost) from customers, orders where customers.customer_id = orders.customer_id and order_flag = "Y" and order_date between "01/01/2004" and "12/31/2004" group by 1, 2 Давайте вашу модернизированную схему и запрос, время выполнения я сейчас померяю для своей задачи и потом на том же железе - для вашего варианта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 22:18 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
У меня есть четкое убеждение, что вышеописанная идея "универсального хранилища" подходит только для создания справочников номенклатурных позиций, так как там довольно мало реальных записей (под этой цифрой я подразумеваю 50000-60000). Если при этом учесть, что в "универсальном хранилище" записей, описывающих каждую позицию, будет порядка в 5 раз больше, то с производительностью системы, в которой все так реализовано, будет все понятно. Городить бизнес-логику в такой системе я думаю, не есть удобно, а довольно тяжело. Надо ведь реализовать такие вещи, как ссылочную целостность, уникальность и др. Говорю я, что тяжело, так как сам создавал такую систему.Она поддерживала и целостность и уникальность (как по простым поля, так и по составным) и прочее, но именно из-за своей производительности "база данных в базе данных" смысл имеет очень малый. Опять таки, можно же добавлять данные непосредственно в таблицы словаря БД (чур меня) и будет та же "универсальность" ... -:) Кстати, в инете полно таких "универсальных хранилищ". Если надо, то когда выйду на работу, моги кинуть ссылки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 22:19 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32853154&tid=1545998]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
91ms |
get tp. blocked users: |
2ms |
| others: | 263ms |
| total: | 466ms |

| 0 / 0 |
