|
|
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
... конечно если эта логика - не действительно ресурсоёмкие задачи по поиску всевозможных оптимумов, распознаванию и преобразованию форматов и т.д., для решения которых количество ресурсов, необходимое для извлечения, передачи и сохранения данных, мало по сравнению с количеством, необходимым для расчётов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 16:32 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
kilaviВ данном случае, это голосование всего лишь показывает, что сообщество РСДН, в большинстве своем, имеет другую точку зрения, чем сообщество SQL, вот и все.Я подозреваю, что сообщество ЖЖ или Анекдот.РУ будет иметь вообще третье мнение: "Все на.... лучше выпей ПИВА!" Интересно, что из этого следует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 16:38 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
mcureenab ChAВы, правда, считаете, что развитие, в частности - технологий, определяется голосованием ?Естественно. Большинство современных IT стандартов принято голосованием поставщиков решений базирующихся на этих стандартах. Лишь немногие компании могут себе позволить создавать собственные стандарты de'facto. Большинство компаний поменьше входят в группы по стандартизации и общими усилиями устанавливают мировой порядок. Технология, которую никто не принимает и не поддерживает не развивается и умирает.Вы не слишком далеко заходите в своей интерпретации голосования ? И какое отношение к ней имеет голосование посетителей rsdn ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 16:45 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
ChA mcureenab ChAВы, правда, считаете, что развитие, в частности - технологий, определяется голосованием ?Естественно. Большинство современных IT стандартов принято голосованием поставщиков решений базирующихся на этих стандартах. Лишь немногие компании могут себе позволить создавать собственные стандарты de'facto. Большинство компаний поменьше входят в группы по стандартизации и общими усилиями устанавливают мировой порядок. Технология, которую никто не принимает и не поддерживает не развивается и умирает.Вы не слишком далеко заходите в своей интерпретации голосования ? И какое отношение к ней имеет голосование посетителей rsdn ? Не понял вопросов. Наверное трава закончилась. (Прости, tigra, не поделился.) Я никакое голосование не интерпретировал. Речь только о том, что промышленные стандарты, в том числе в области IT, часто принимаются голосованием. Форумы RSDN и SQL.RU никакой юридической силы не имеют, так что голосование их участников скорее отражает общественное мнение, а учитывать его в принятии решения или нет, каждый решает сам за себя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 16:59 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
mcureenabНе понял вопросов.Ну и ладно, не стоит себя напрягать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 17:23 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
softwarerс моей точки зрения большинство коллег пишет вообще "однозвенные" системы - сколько бы они ни считали сами, но закладывают одно "основное" звено и одно-два-три сугубо технических, уровня "драйвера клавиатуры". ИМХО скорее и "драйвера" и т.н. "бизнес-логика" в большей или меньшей степени размазываются между всеми этими слоями-звеньями. Больше их - больше степень размазывания. Хотя какое-то звено считается основным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 17:39 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
ОдинИМХО скорее и "драйвера" и т.н. "бизнес-логика" в большей или меньшей степени размазываются между всеми этими слоями-звеньями. В хорошо спроектированной системе - да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 19:13 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
Bely kilaviВ данном случае, это голосование всего лишь показывает, что сообщество РСДН, в большинстве своем, имеет другую точку зрения, чем сообщество SQL, вот и все.Я подозреваю, что сообщество ЖЖ или Анекдот.РУ будет иметь вообще третье мнение: "Все на.... лучше выпей ПИВА!" Интересно, что из этого следует? из этого следует, что некоторым, очень трудно сделать самостоятельно выводы, не более того. По существу есть что добавить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2007, 08:36 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
mcureenab Alex_Toms При получении запросов select, insert, update, delete сервак: 1: сначала призводит синтаксический разбор текста 2: затем компилирует 3: производит оптимизацию плана запроса 4: и только после этого выполняет сам запрос. При использовании ХП, первые 3 пункта выполняются после изменении текста ХП, а при вызове сразу пункт 4, при этом при экономятся ресурсы сервера, и выигрыш от этого бывает очень значительный. В Оракле и при использовании ХП всё происходит точно так же с п.1 по п.4. Может в MSSQL это не так? Но тогда после изменения данных останется старый план запроса. Это не так. Ни для Oracle, ни для MS SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 09:20 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
ИМХО, если вычислительная сложность алгоритма, где N стоимость выборки данных - <= О(N) - его нужно выполнять в БД - между О(N) и O(N**2) - думать надо - >= O(N**2) - выносить из базы Задача зарплаты подпадает под первую категорию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 10:28 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
drev mcureenab Alex_Toms При получении запросов select, insert, update, delete сервак: 1: сначала призводит синтаксический разбор текста 2: затем компилирует 3: производит оптимизацию плана запроса 4: и только после этого выполняет сам запрос. При использовании ХП, первые 3 пункта выполняются после изменении текста ХП, а при вызове сразу пункт 4, при этом при экономятся ресурсы сервера, и выигрыш от этого бывает очень значительный. В Оракле и при использовании ХП всё происходит точно так же с п.1 по п.4. Может в MSSQL это не так? Но тогда после изменения данных останется старый план запроса. Это не так. Ни для Oracle, ни для MS SQL. Интересно, как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 14:40 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
mcureenab drev mcureenab Alex_Toms При получении запросов select, insert, update, delete сервак: 1: сначала призводит синтаксический разбор текста 2: затем компилирует 3: производит оптимизацию плана запроса 4: и только после этого выполняет сам запрос. При использовании ХП, первые 3 пункта выполняются после изменении текста ХП, а при вызове сразу пункт 4, при этом при экономятся ресурсы сервера, и выигрыш от этого бывает очень значительный. В Оракле и при использовании ХП всё происходит точно так же с п.1 по п.4. Может в MSSQL это не так? Но тогда после изменения данных останется старый план запроса. Это не так. Ни для Oracle, ни для MS SQL. Интересно, как? Давайте отложим вопрос "как", и разберём Ваше утверждение. Вроде бы не совсем осмысленно при создании любого программного модуля выполнять пункт 2, чтобы потом, при его запуске выполнять пункт 1, правда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 14:56 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
drevВроде бы не совсем осмысленно при создании любого программного модуля выполнять пункт 2, чтобы потом, при его запуске выполнять пункт 1, правда? Мне утверждение Алекса также представляется не то чтобы абсолютно верным, но в данном случае я бы не стал говорить так категорично..... Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 15:16 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
mcureenabИнтересно, как? В Оракле примерно так : Проверили синтаксис (вруг где буковку пропустили) Проверили доступность объектов, перевели все в один регистр и т.п. (semantic check) Посчитали ХЭШ Проискали по хэшу в библиотечном кеше (у запрос есть ещё всякие фишки вроде текущей сортировки и т.п. их тоже надо не забыть) Если нашлось и объекты на которые ссылается запрос те же (т.е. синонимами не обманули то берём план из кэша и вперёд (soft parse) Иначе - hard parse, строим дерево разбора и план выполнения и кладём всё это в library cache перед тем как выполнить (авось кому сгодится) Кто и когда делает существующие разборы невалидными (то ли analayze table\index то ли ещё кто) я не знаю но делает точно, т.к. при изменении статистики план меняется. Где то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 15:57 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
drevДавайте отложим вопрос "как", и разберём Ваше утверждение. Вроде бы не совсем осмысленно при создании любого программного модуля выполнять пункт 2, чтобы потом, при его запуске выполнять пункт 1, правда? У Оракла на этот счёт другое мнение. Собственно синтаксический разбор SQL запроса занимает очень малую часть времени. Значительно больше времени занимает построение оптимального плана - суть оптимизирующая компиляция запроса с учётом текущего состояния БД. Так что выдумывать некий p-code для хранения разобранного запроса без плана, только чтобы не выполнять синтаксический анализ нет смысла. Глобальный кэш SQL запросов и локальный кэш курсоров вообще позволяет в большинстве случаев пропустить этап компиляции (hard parse) и сразу перейти к выполнению существующего плана (soft parse, или no parse). PS. Вы не задумывались, почему до сих пор существуют и успешно развиваются скриптовые языки? Например для серверных приложений, которые многократно выполняют одни и теже процедуры однажды скомпилированный на этапе выполнения скрипт будет работать, работать и работать. А в случае изменение внешних скриптов или БД не потребует ручной перекомпиляции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 16:53 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
mcureenab drevДавайте отложим вопрос "как", и разберём Ваше утверждение. Вроде бы не совсем осмысленно при создании любого программного модуля выполнять пункт 2, чтобы потом, при его запуске выполнять пункт 1, правда? У Оракла на этот счёт другое мнение. Собственно синтаксический разбор SQL запроса занимает очень малую часть времени. Значительно больше времени занимает построение оптимального плана - суть оптимизирующая компиляция запроса с учётом текущего состояния БД. Так что выдумывать некий p-code для хранения разобранного запроса без плана, только чтобы не выполнять синтаксический анализ нет смысла. Глобальный кэш SQL запросов и локальный кэш курсоров вообще позволяет в большинстве случаев пропустить этап компиляции (hard parse) и сразу перейти к выполнению существующего плана (soft parse, или no parse). Всё, что вы говорите, верно для "простых запросов". Для stored procedures это не совсем так. Предствавим себе , которая содержит пару тысяч строк кода, внутри которой парочка селектов и инсёртов и куча "процедурной" логики. В данной ситуации, синтаксический анализ занимает недопустимо большое время по сравнению с работой оптимизатора и выполнением вместе взятыми. Попробуйте создать подобную процедуру, и посмотрите сколько времени это займёт. А потом запустите её. И сравните время. Для одного из решений этой проблемы введен statement level RECOMPILE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 22:45 |
|
||
|
Тонкий или толстый клиент
|
|||
|---|---|---|---|
|
#18+
softwarer drevВроде бы не совсем осмысленно при создании любого программного модуля выполнять пункт 2, чтобы потом, при его запуске выполнять пункт 1, правда? Мне утверждение Алекса также представляется не то чтобы абсолютно верным, но в данном случае я бы не стал говорить так категорично..... Код: 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. 1. В данной ситуации я отвечал не на пост Алекса, а на ответ на этот пост mcureenab. 2. В приведеном Вами примере происходит, ИМХО, не перекомпиляция, а отложенная резолюция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2007, 22:54 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34642298&tid=1544417]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
200ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 253ms |
| total: | 558ms |

| 0 / 0 |
