|
|
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредЗначит ли это, что "вертикальное партиционирование" в Oracle отпадает, и нужно реализовывать в Oracle "какой-нибудь EAV-like dasign" мне сложно понять. Попробуйте спросить у Гугля, что эти слова значат - может, станет яснее. Правда, не ответит на вопрос "что же нужно реализовывать" - например, разреженные данные очень эффективно хранятся в analytic workspace-ах, но это не значит, что их надо использовать для каждой задачи. БредИ это, надо думать, тоже мое право. Безусловно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 19:50 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
ChA БредЯ не смог обнаружить нечистоту, к сожалению, и обратился с вопросом к специалистам.В данном случае лучше было писать "не" и "чистоту" раздельно, хотя фразу это все равно не спасает. Начнем с того, как Вы определили объем БД после выполнения всех операций ? В EM в свойствах БД посмотрели ? Закончите, пожалуйста, тем каков правильный результат, и дело с концом. Я же уже согласился с полной бессмысленностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 19:51 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
ChA БредЯ не смог обнаружить нечистоту, к сожалению, и обратился с вопросом к специалистам.В данном случае лучше было писать "не" и "чистоту" раздельно, Это было бы орфографической ошибкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 19:54 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
SergSuperкакая у нас аллергия на сильноразреженность Она в природе человеческой. Мы же не радуемся сильно разреженным товарам в магазинах и не отправляемся в отпуск с сильно разреженными вещами в чемоданах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 19:56 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредЗакончите, пожалуйста, тем каков правильный результат, и дело с концом. Я же уже согласился с полной бессмысленностью.Я не знаю, что Вы подразумеваете под правильным результатом. Грубый пример стандартного расчета объема таблицы уже был приведен. Все сильные отклонения от него могут быть результатом неизвестных мне факторов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 19:59 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто было бы орфографической ошибкой. Модератор: Давайте остановимся на этом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:01 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредТам разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено. Способы может быть и разные, но все сводится к одному - есть некий ключ и аттрибут. Сделайте так же на SQL - и тоже не надо будет бороться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:03 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer SergSuperкакая у нас аллергия на сильноразреженность Она в природе человеческой. Мы же не радуемся сильно разреженным товарам в магазинах и не отправляемся в отпуск с сильно разреженными вещами в чемоданах Интересный пример с чемоданами. Сложно представить что-либо более разреженное. Я уж не говорю, что в любом магазине просто потрясающая разреженность товаров. Постоянно большинство нужных предметов нельзя купить в конкретном магазине... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:04 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
SergSuper БредТам разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено. Способы может быть и разные, но все сводится к одному - есть некий ключ и аттрибут. Сделайте так же на SQL - и тоже не надо будет бороться Вы мне предлагаете сделать количество колонок в таблице не ограниченным, и не занимать место под несуществующие данные в SQL Server ??? Я этого сделать не могу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:08 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредЯ уж не говорю, что в любом магазине просто потрясающая разреженность товаров. Постоянно большинство нужных предметов нельзя купить в конкретном магазине... "Потрясающая разреженность" здесь относится к "товарам в совокупности", к тому, что я назвал "данными", противопоставив их "таблицам". То, что Вы предпочли трактовать как поправку в терминологии. Магазины - как раз пример вертикального партиционирования как варианта хранения разреженных данных. Благодаря ему во-первых полки магазина плотно забиты, во-вторых, гвозди как правило можно купить рядом с молотками, а в-третьих, покупая хлеб, мы не рискуем обнаружить в нем завалившийся гвоздь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:10 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
ChA БредЗакончите, пожалуйста, тем каков правильный результат, и дело с концом. Я же уже согласился с полной бессмысленностью.Я не знаю, что Вы подразумеваете под правильным результатом. Грубый пример стандартного расчета объема таблицы уже был приведен. Все сильные отклонения от него могут быть результатом неизвестных мне факторов. Я могу только предположить, что в Вашем грубом примере есть серьезная ошибка. Но, предположим, что ошибка была у меня (куда-то не туда смотрел). Тогда: SQL Server 2005 - 4 Гб Cache 5.2 - 17 Мб Oracle ??? - 1.11 Гб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:12 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer БредЯ уж не говорю, что в любом магазине просто потрясающая разреженность товаров. Постоянно большинство нужных предметов нельзя купить в конкретном магазине... "Потрясающая разреженность" здесь относится к "товарам в совокупности", к тому, что я назвал "данными", противопоставив их "таблицам". То, что Вы предпочли трактовать как поправку в терминологии. Магазины - как раз пример вертикального партиционирования как варианта хранения разреженных данных. Благодаря ему во-первых полки магазина плотно забиты, во-вторых, гвозди как правило можно купить рядом с молотками, а в-третьих, покупая хлеб, мы не рискуем обнаружить в нем завалившийся гвоздь. Лирика. Вы продолжаете настаивать на том, что данные могут быть разреженными (что это такое я понять не могу - не дано), а таблицы не могут. На этой оптимистической ноте позвольте закончить обсуждение изначально бессмысленного вопроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:17 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто было бы орфографической ошибкой.Уважаемый MasterZiv, рекомедую Вам ознакомиться со смыслом слова "нечистота", например, с помощью Google. P.S. Модератор, так лучше ? Модератор: Уважаемый ChA, рекомендую Вам ознакомиться с правилами хорошего тона ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:20 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредТам разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено. Конечно не ограничено. Ведь там нет ни того, ни другого. Ограничение на размер "ключа" всё же есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 20:22 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредВы мне предлагаете сделать количество колонок в таблице не ограниченным, и не занимать место под несуществующие данные в SQL Server ??? Я этого сделать не могу. Я ничего не предлагаю, я просто объясняю что структура данных в Cache эквивалентна таблице с двумя полями. Снимаю шляпу перед маркетологами Cache, которые для этого сумели придумать красивое название "разряженные массивы" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 23:02 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредБольшое спасибо. Пусть и бессмысленный, но результат: В таблице 1000 колонок типа Integer. 1 000 000 записей, и только в последней колонке каждой записи записали значение=1. SQL Server 2005 - 17.2 Gb Cache 5.2 - 17 Mb Oracle ??? - 1.11 Gb А разве любой из таких вот "отдельных результатов" нельзя назвать бессмысленным? Наверное нужно закрывать этот раздел на форуме.Гм. Не знаю - зачем я это делал :), но вот результаты Firebird Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. Заносим 1 в последнюю колонку : Код: plaintext Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2007, 01:37 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Гм, чего-то со скриптом я намутил - ночь наверное ;) Создавать таблицу можно и так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2007, 01:48 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Простите, а где ЧАЛ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2007, 02:01 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредМожет чего не правильно настроил: В таблице 1000 колонок типа Integer. 1 000 000 записей, и только в одной колонке каждой записи записал значение=1. SQL Server 2005 - 17.2 Gb Cache 5.2 - 17 Mb И, если кто может, скажите какой результат в Oracle? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2007, 09:18 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Бред говорил про базы данных, кажется. А именно про хранение "сильно разреженных таблиц", в которых иногда есть потребность. Но пусть это будет совершенно бессмысленным, в отличие от Ваших, всегда осмысленных, "сравнениях СУБД". Я не против. Sybase IQ именно так и хранит данные - по столбцам. Если стобец пустой, или там "сильноразряженный", то он практически ничего на диске не занимает, независимо от числа строк в таблице. Более того - если в таблице миллион строк километровой длины, но в строках хранится всего десять - сто - тысяча уникальных значений, то эти значения будут закодированы и храниться будут толко пара байт (и образцы строк). Такая вот звездообразная схема реализована "унутре думателя". При всем этом IQ является вполне себе реляционной СУБД (а не кашей какой-то), и даже Transact SQL понимает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 01:08 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey БредМожет чего не правильно настроил: В таблице 1000 колонок типа Integer. 1 000 000 записей, и только в одной колонке каждой записи записал значение=1. SQL Server 2005 - 17.2 Gb Cache 5.2 - 17 Mb И, если кто может, скажите какой результат в Oracle? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей. А где тут 1000 колонок типа int ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 01:11 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Выбегалло Bogdanov Andrey БредМожет чего не правильно настроил: В таблице 1000 колонок типа Integer. 1 000 000 записей, и только в одной колонке каждой записи записал значение=1. SQL Server 2005 - 17.2 Gb Cache 5.2 - 17 Mb И, если кто может, скажите какой результат в Oracle? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей. А где тут 1000 колонок типа int ? А, пардон, сразу не просек. Ну да, ну да - это та самая схема хранения, в которой элементарный запрос надо полдня продумывать, а потом сервер полдня джойны хреначит. Знакомая штука. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 01:15 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Выбегалло А где тут 1000 колонок типа int ? А где у Cashe 1000 колонок? Там вообще нет ни одной колонки. Выбегалло А, пардон, сразу не просек. Ну да, ну да - это та самая схема хранения, в которой элементарный запрос надо полдня продумывать, а потом сервер полдня джойны хреначит. Знакомая штука. Время продумывания и время выполнения зависит в основном от умственных способностей продумывающего, а не от сервера и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 09:03 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
pavelvp БредТам разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено. Конечно не ограничено. Ведь там нет ни того, ни другого. Ограничение на размер "ключа" всё же есть. Где "там"? Я не так давно познакомился с Cache, но успел увидеть три СУБД. И во всех были таблицы и колонки. Может это у Вас ревность? Потому что "там" много чего есть. Лучше опубликуйте результат бессмысленного теста для Линтер, и сравните его, конечно же, с SQL Server. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 10:42 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
SergSuper БредВы мне предлагаете сделать количество колонок в таблице не ограниченным, и не занимать место под несуществующие данные в SQL Server ??? Я этого сделать не могу. Я ничего не предлагаю, я просто объясняю что структура данных в Cache эквивалентна таблице с двумя полями. Снимаю шляпу перед маркетологами Cache, которые для этого сумели придумать красивое название "разряженные массивы" Не правильно объясняете - не знаю - от незнания или умышленно? Структура данных в Cache эквивалентна, помимо прочего, таблице с неограниченным числом полей. А маркетинг у Cache просто нулевой. И у меня создается ощущение, что это совсем не беспокоит Intersystems. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 10:45 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=34681846&tid=1553279]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
32ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 163ms |

| 0 / 0 |
