|
|
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyВ чем разница между DW с процедурой с курсором и просто с запросом? И там и там надо написать запрос, только в первом случае запрос формируется на серверной стороне, а во втором на клиентской. Причем ничто не мешает и во втором случае хранить запрос в БД. Кстати, а план исподнения Вы тоже в БД собираетесь хранить в таком случает? Что толку то от текста. К тому же на некоторых серверах есть определенные аспекты удобные для реализации через SP, например raw level security... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2006, 11:42 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
PL99На клиенте динамически формировать запрос ничуть не удобнее, чем на сервере, по мне так как раз наоборот, но тут,что называется, на вкус и цвет... :-) Кроме того, процедура позворяет написать статический код, который, хотя и выглядит ужасно, но зато обеспечивает требуемую производительность. Я говорю об удобстве в ситуации когда опытный пользователь может сам писать произвольные запросы к базе либо непосредственно на SQL либо используя некий конструктор. У меня вообще есть сомнения, что это можно реализовать с помощью DW на SP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2006, 15:51 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Локшин Марк Anatoly MoskovskyВ чем разница между DW с процедурой с курсором и просто с запросом? И там и там надо написать запрос, только в первом случае запрос формируется на серверной стороне, а во втором на клиентской. Причем ничто не мешает и во втором случае хранить запрос в БД. Кстати, а план исподнения Вы тоже в БД собираетесь хранить в таком случает? Что толку то от текста. К тому же на некоторых серверах есть определенные аспекты удобные для реализации через SP, например raw level security... Какая разница где хранится план? При выполнении одинаковых запросов в ХП и с клиента у них планы будут одинаковыми. Насчет RLS - в Oracle еще с 8i есть поддержка этого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2006, 16:00 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyПри выполнении одинаковых запросов в ХП и с клиента у них планы будут одинаковыми. Не знаю как там в Oracle, а в MS SQL план исполнения хранимой процедуры строится при ее созданиии и хранится в базе, в отличие от запроса, который, в принципе, тоже может иметь сохраненный план исполнения в кэше, но в любом случае, не далее очередного restart'а сервера. Сдается мне, что и Oracle должет (может???) себя вести таким же образом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2006, 16:29 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Локшин Марк Anatoly MoskovskyПри выполнении одинаковых запросов в ХП и с клиента у них планы будут одинаковыми. Не знаю как там в Oracle, а в MS SQL план исполнения хранимой процедуры строится при ее созданиии и хранится в базе, в отличие от запроса, который, в принципе, тоже может иметь сохраненный план исполнения в кэше, но в любом случае, не далее очередного restart'а сервера. Сдается мне, что и Oracle должет (может???) себя вести таким же образом. План в общем случае зависит от данных, поэтому хранить его не всегда полезно. В Oracle нужно явно указывать если требуется сохранить план запроса, и это не зависит от того в ХП выполняется запрос или где либо еще. И это забота DBA принимать такое решение хранить или нет. Вообще я говорил о том, что для операции RETRIEVE в DW использовать ХП в ORACLE (см. исходный вопрос и сабж) бессмысленно, поскольку все тоже самое можно проделать с клиента без более сложного кодирования и отладки серверной части. И даже более того - часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать. Еще раз напоминаю, что речь идеть только об ORACLE и только об операции RETRIEVE. Единственный аргумент для использования ХП в этой ситуации - это требования безопасности (например нужно запретить произвольные запросы к базе) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2006, 11:01 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyВообще я говорил о том, что для операции RETRIEVE в DW использовать ХП в ORACLE (см. исходный вопрос и сабж) бессмысленно, поскольку все тоже самое можно проделать с клиента без более сложного кодирования и отладки серверной части. И даже более того - часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать. Еще раз напоминаю, что речь идеть только об ORACLE и только об операции RETRIEVE. Абсолютно, категорически, на 100 % НЕ согласен . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2006, 15:52 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Филипп Anatoly MoskovskyВообще я говорил о том, что для операции RETRIEVE в DW использовать ХП в ORACLE (см. исходный вопрос и сабж) бессмысленно, поскольку все тоже самое можно проделать с клиента без более сложного кодирования и отладки серверной части. И даже более того - часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать. Еще раз напоминаю, что речь идеть только об ORACLE и только об операции RETRIEVE. Абсолютно, категорически, на 100 % НЕ согласен . Было больно, но неубедительно :) Где аргументация? Опровергните эти утверждения из процитированного Вами (желательно примерами): 1) тоже самое можно проделать с клиента 2) часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать И заодно и это: 3) Использование ХП снижает переносимость серверной части между разными СУБД. Как следствие - удорожание такой миграции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2006, 16:13 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
2Anatoly Moskovsky : Я, думаю, что Вам это будет небезынтересно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 06:30 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky Филипп Anatoly MoskovskyВообще я говорил о том, что для операции RETRIEVE в DW использовать ХП в ORACLE (см. исходный вопрос и сабж) бессмысленно, поскольку все тоже самое можно проделать с клиента без более сложного кодирования и отладки серверной части. И даже более того - часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать. Еще раз напоминаю, что речь идеть только об ORACLE и только об операции RETRIEVE. Абсолютно, категорически, на 100 % НЕ согласен . Было больно, но неубедительно :) Где аргументация? Опровергните эти утверждения из процитированного Вами (желательно примерами): 1) тоже самое можно проделать с клиента 2) часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать И заодно и это: 3) Использование ХП снижает переносимость серверной части между разными СУБД. Как следствие - удорожание такой миграции. Пункт 1 - Объектные типы Oracle. Вложенные таблицы и много другое. :) Пункт 2 - Раскрою вам большой секрет - динамический SQL есть и на серверной стороне. Пункт 3 - довольно сомнителен. Или вы всегда пишете запросы только с использованием ANSI SQL? НЕ ВЕРЮ! Ибо гораздо проще, приятней и понятней написать запрос на оракловом диалекте и работать такой запрос будет лучше, чем тоже самое изображать ANSI SQL-compilant. И даже это не гарантирует Вам одинакового поведения на разных СУБД. Так что ой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 11:32 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Геннадич2Anatoly Moskovsky : Я, думаю, что Вам это будет небезынтересно Прочитал. Не то. Там спор идет о том, где должна обрабатываться ВСЯ бизнес-логика, на сервере или на клиенте. Для меня же бизнес-логика делится на две части: 1) модификация данных 2) представление данных п.1 должен подчиняться единым для всех пользователей системы правилам, поэтому эта часть должна выполняться на сервере (БД, сервер приложений), чтобы обеспечить целостность данных. п.2 - это субъективное, здесь разработчик не может диктовать пользователю, в каких разрезах ему можно смотреть данные (вплоть до использования напрямую SQL). Поэтому п.2 должен выполняться на клиенте. Выше я говорил только про п.2, поскольку DW.RETRIEVE безусловно является частью процесса представления данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 12:14 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky Еще раз напоминаю, что речь идеть только об ORACLE и только об операции RETRIEVE. AndrewNОпровергните эти утверждения из процитированного Вами (желательно примерами): 1) тоже самое можно проделать с клиента 2) часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать И заодно и это: 3) Использование ХП снижает переносимость серверной части между разными СУБД. Как следствие - удорожание такой миграции. Пункт 1 - Объектные типы Oracle. Вложенные таблицы и много другое. :) Пункт 2 - Раскрою вам большой секрет - динамический SQL есть и на серверной стороне. Пункт 3 - довольно сомнителен. Или вы всегда пишете запросы только с использованием ANSI SQL? НЕ ВЕРЮ! Ибо гораздо проще, приятней и понятней написать запрос на оракловом диалекте и работать такой запрос будет лучше, чем тоже самое изображать ANSI SQL-compilant. И даже это не гарантирует Вам одинакового поведения на разных СУБД. Так что ой. 1. Ну что же, приведите пример ХП пригодной для использования с DW и которую нельзя переписать на PB (только что-то компактное, чтоб сразу была видна суть, а то у меня есть чем заняться помимо этого форума :). Насчет объектов в таблицах. А их кто-то использует? 2. Вы не поверите, я знал и раньше. А теперь состыкуйте динамический SQL в ХП и Datawindow 3. У нас был проект написанный под Oracle. Когда потребовалось его мигрировать на PostgreSQL, то автоматический конвертор DW из Oracle SQL в PostgreSQL был написан за пару недель одним человеком. А вот пакеты так и не удалось автоматом конвертнуть. Так тот проект и дропнули, поскольку переписывать серверную часть было слишком дорого, дешевле клиентам на наши деньги Oracle покупать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 12:40 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky 1. Ну что же, приведите пример ХП пригодной для использования с DW и которую нельзя переписать на PB (только что-то компактное, чтоб сразу была видна суть, а то у меня есть чем заняться помимо этого форума :). Ну, строго говоря, подобные ситуации все же возможны. :) Например, хранимая собирает нужные данные в промежуточной таблице. Это полезно, когда объем обрабатываемых данных велик, а результат мал. Или если надо сначала полазить в закрытых для общего доступа таблицах. ИМХО, массовое использование хранимых для select'а -- это фирменная фишка MSSQL. Мне иногда кажется, что он впринципе заточен восновном под такую работу. :) Anatoly Moskovsky2. Вы не поверите, я знал и раньше. А теперь состыкуйте динамический SQL в ХП и Datawindow Нет ничего не возможного. Просто "динамика" может быть разной: список колонок, условия запроса и т.п. Anatoly Moskovsky3. У нас был проект написанный под Oracle. Когда потребовалось его мигрировать на PostgreSQL, то автоматический конвертор DW из Oracle SQL в PostgreSQL был написан за пару недель одним человеком. А вот пакеты так и не удалось автоматом конвертнуть. Так тот проект и дропнули, поскольку переписывать серверную часть было слишком дорого, дешевле клиентам на наши деньги Oracle покупать. С переносимостью действительно не все так просто, т.к. языки хранимых почти у всех серверов только с виду походие, а реально ощутимо разные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 13:47 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Oleg1 Anatoly Moskovsky 1. Ну что же, приведите пример ХП пригодной для использования с DW и которую нельзя переписать на PB (только что-то компактное, чтоб сразу была видна суть, а то у меня есть чем заняться помимо этого форума :). Ну, строго говоря, подобные ситуации все же возможны. :) Например, хранимая собирает нужные данные в промежуточной таблице. Это полезно, когда объем обрабатываемых данных велик, а результат мал. Ничто не мешает выполнить запрос, заполняющий временную таблицу, из PB. Или если надо сначала полазить в закрытых для общего доступа таблицах.Для сокрытия данных в Oracle вполне достаточно view и RLS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 14:20 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Ха-ха-ха. Мистер очень занят, чтоб немного подумать самостоятельно. Так пишите же как вам нравится! Btw в драйверах O84, O92 исправили ошибку с парсением SQL? Или все по-прежнему спотыкается на ровных местах?! ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 15:39 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
AndrewNХа-ха-ха. Мистер очень занят, чтоб немного подумать самостоятельно. Так пишите же как вам нравится! Убедительно. Btw в драйверах O84, O92 исправили ошибку с парсением SQL? Или все по-прежнему спотыкается на ровных местах?! ) Не знаю. Я использую O73. Он работает со всеми ораклами. И в нем нет никаких проблем с SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 15:59 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Надеюсь и ПБ у вас 5-ой версии. Good luck! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 16:38 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
to AndrewN Каждый пишет как может, конкретный вариант решения зависит от постановки задачи Я использовал оба варианта (хотя, каюсь, к Pb ХП не привешивал), также разрабатывал и хранимые процедуры, так что аргументов в пользу какого-либо из вариантов знаю достаточно. Незачем оскорблять друг друга. У каждого свой подход к разработке, свои задачи - поэтому выбор есть у каждого (опять же СУБД у всех разная). Просто, выбор оптимального варианта - есть наша цель. Хотя, честно признаюсь, если есть DW, чаще всего, незачем использовать хранимые процедуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 18:13 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky Филипп Anatoly MoskovskyВообще я говорил о том, что для операции RETRIEVE в DW использовать ХП в ORACLE (см. исходный вопрос и сабж) бессмысленно, поскольку все тоже самое можно проделать с клиента без более сложного кодирования и отладки серверной части. И даже более того - часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать. Еще раз напоминаю, что речь идеть только об ORACLE и только об операции RETRIEVE. Абсолютно, категорически, на 100 % НЕ согласен . Было больно, но неубедительно :) Где аргументация? Опровергните эти утверждения из процитированного Вами (желательно примерами): 1) тоже самое можно проделать с клиента 2) часть функциональности (полностью динамические запросы) вообще на ХП нельзя сделать И заодно и это: 3) Использование ХП снижает переносимость серверной части между разными СУБД. Как следствие - удорожание такой миграции. 1) Нельзя. Вот живой пример. В нашем продукте, ориентированном на Medical Malpractice Insurance несколько модулей. 2 основных - Claims и Policy. Claims - 50%/50% с точки зрения функциональности между PB и PL/SQl (Oracle), Policy - 25%/75% с точки зрения функциональности между PB и PL/SQl. Claims включает в себя мини полиси. Клиент, когда создает Claims, может использовать покрытия застрахованного человека как из большой Полиси, так и из мини. Чтоб найти и показать покрытия (coverage), имеется такая процедура Код: 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. 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. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512. 513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 2 - динамический SQL есть и на серверной стороне, а за использование его в РВ я подчинённых увольняю :-) 3. По сути дела существует только 3 метода переносимости приложений написанных на РВ между разными СУБД: а) Все DW нарисованы в графическом режиме. Я в этот метод не верю, поскольку он приводит к наименьшему знаменателю с точкм зрения использования возможностей СУБД в DW б) Иметь параллельные наборы DW для каждой СУБД в) Весь CRUD, включая DW делать через хранимые процедуры и портать только хранимые процедуры. Я работал на продукте (успешно применяющемся в очень многих университетах США), который использует именно такой подход. На мой взгляд вариант в более поддерживаем, чем вариант б ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 22:02 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
2 Anatoly Moskovsky: Очень часто бывает, что аргументы для запроса, включая их количество, не меняются, а вот технология вычисления данных меняется. И что же получается в вашем случае: для изменения одной формы отчёта надо перекомпиливать все отчёты, которые входят в pbd, после этого не будет лишним протестировать их все. Но если данные вычисляются на сервере, то для изменения отчёта совсем не надо трогать ни exe ни pbd, - только процедуру на сервере. А по поводу универсального софта для любых баз - это В САД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 06:31 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
2 Anatoly Moskovsky: И еще, тут помнится обсуждалась тема про автоматическую параметризацию запросов. Так вот, использование stored procedures не требует наличия такого механизма в СУБД, в отличие от тех запросов, которые формируются в DataWindow, для повторного использования плана исполнения запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 10:29 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
spas2001to AndrewN .... Незачем оскорблять друг друга. ... Что-то было немного эмоционально. Но я не вижу чтобы кто-то кого-то оскорблял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 11:15 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
to Филипп: 1. Не увидел ничего такого что нельзя сделать на клиенте. Фильтр запроса там формируется в зависимости от некоторых параметров (скорее всего это права доступа и прикладные параметры) Для переноса на клиентскую часть с сохранением системы прав можно применить метки данных (которые так или иначе можно было реализовать в любой версии Оракла) Анализ остальных параметров, не относящихся к правам, просто один к одному переносится на клиент. 2. Ну хоть как-то обоснуйте. Я вижу только то что планы динамических запросов могут быть просто ужасными. Но на то есть DBA с ограничениями ресурсов выделяемых на запросы. 3. Я уже приводил пример приложения в котором DW (не в графике) автоматом переводились из Oracle в Postgres. Так что есть и другие способы мигрировать. А вот портирование ХП в другую СУБД оказалось намного сложнее (причем как руками так и автоматом) чем портирование SQL запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 12:09 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
ГеннадичОчень часто бывает, что аргументы для запроса, включая их количество, не меняются, а вот технология вычисления данных меняется. И что же получается в вашем случае: для изменения одной формы отчёта надо перекомпиливать все отчёты, которые входят в pbd, после этого не будет лишним протестировать их все. Но если данные вычисляются на сервере, то для изменения отчёта совсем не надо трогать ни exe ни pbd, - только процедуру на сервере. А по поводу универсального софта для любых баз - это В САД. У нас все статические отчеты хранятся в таблице на сервере (грубо говоря в виде синтаксиса DW) и распространяются в таких же патчах что и структура БД, отдельно от EXE. ХП в них используются только там где нужно для оптимизации, а не как обязательное условие. Про универсальный софт я вообще не говорил - откуда это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 12:20 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Локшин Марк2 Anatoly Moskovsky: И еще, тут помнится обсуждалась тема про автоматическую параметризацию запросов. Так вот, использование stored procedures не требует наличия такого механизма в СУБД, в отличие от тех запросов, которые формируются в DataWindow, для повторного использования плана исполнения запроса. Ну нашли же вроде решение. Тем более что для последних Ораклов это уже неактуально :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 12:25 |
|
||
|
DW и процедура Oracle
|
|||
|---|---|---|---|
|
#18+
Я хочу скорректировать свою позицию в результате обсуждения. Раньше я говорил, что использовать ХП в DW для выборки бессмысленно. Теперь я считаю, что DW на ХП имеют такое же право на существование как и DW на SELECT, кроме полностью динамических запросов - их по-прежнему не имеет смысл выполнять через ХП. Но указанные мной недостатки сохраняются: - ХП сложнее отлаживать - SQL намного проще портировать чем ХП ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 12:47 |
|
||
|
|

start [/forum/topic.php?fid=15&msg=34106374&tid=1337524]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
151ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 196ms |
| total: | 453ms |

| 0 / 0 |
