|
Параметризовать в функции название связанного сервера
|
|||
---|---|---|---|
#18+
Код: sql 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.
"да", - тут "всё плохо" :) начиная с @xml_data varchar( 8000 ) (можно "решить" циклом по рекордсету, отказавшись от xml) и заканчивая правами коннекта на ЛС просто считайте это "иллюстрацией" принципиальной возможности "хотелки" ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 09:28 |
|
Параметризовать в функции название связанного сервера
|
|||
---|---|---|---|
#18+
Гавриленко Сергей Алексеевич Mtgktem "сделайте полное окружение, идентичное "боевому"." SIMPLicity_, Вы что издеваетесь, ради того, чтобы сохранить несколько функций наустанавливать кучу МССкулей, Ораклов, Фаербердов, и... шайтан его знает каких еще серверов-источников данных?? Слабые же духом наверняка задумаются, зачем им беременеть себе мозг с такими функциями, особенно если в обмене данными между системами все уже давно украдено без таких геморроев. Окей! Возвращаемся в 1994 год. Вспоминаем "как бы объектное" программирование. Пишем свой обработчик входящего JSON-a: {Таблица:..., Формат:...., Действие:...., Данные:"<тута, ка ни стронно, ещё один JSON обо Ваши данные НЕформализованы по условию задачи>"} Обработчик вешаем слушать порт (либо напрямую либо прикручиваем к nginx-у) и пишем для него .ini-шку для подключения к нужному нам в данным момент скуль-серверу. Все "потоки данных" как хочут ломятся на сервис (гадят в означенный порт,- удачно или не очень) и отправляют свои данные в Ваше хоронилище. При необходимости проектируете распределённую систему. Такой вариант, кстати, работает. В общем-то web-технологии в общем целом Вашу задачу решили, и уже давно. PS использование xml вместо JSON эту конструкцию формализует ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 22:44 |
|
Параметризовать в функции название связанного сервера
|
|||
---|---|---|---|
#18+
felix_ff Гавриленко Сергей Алексеевич Ржу в голос, простите. То, как они это реализовали, даже к красоте не имеют отношения: скорее маркетологическая галочка в фичах. В целом, абсолютно унылая неработоспособная хрень в большинстве сценариев. не соглашусь с Вами, в целом LS достаточно жизнеспособна, особенно когда мапятся mssql <=> mssql. про коммуникацию к другим СУБД, согласен приходится танцевать с бубнами. Mtgktem, еще раз вопрос: че вы привязались именно к TVF? хотите более менее нормально выстроить ломанную логику используйте хранимые процедуры, нахрена вам именно табличные функции? Поддерживаю. Линкованные сервера MSSQL-MSSQL рулят. Не всё хорошо и гладко, но решает много-много проблем. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 22:46 |
|
Параметризовать в функции название связанного сервера
|
|||
---|---|---|---|
#18+
SIMPLicity_ , это верно, старые дедовские методы работают, проверено, надежно и понятно. И много чего "оттуда" используется и сейчас. Почти как некоторые устройства советских времен, исправные до сих пор - с толстыми проводами, качественным металлом, надежной конструкции, с понятной схемой и инструкцией починки. Но в данном случае задача другая. Никакой из источников данных сам не будет в меня бросаться ни xml-линами ни json-нами, если его не окучить особым образом. А окучивать каждый источник никто не будет. С точки зрения технологий, кроме разрешения прав доступа, источники данных и не должны ничего обрабатывать или отдавать xml и вообще ничего знать об этом. В принципе, связанные сервера задачу забора данных (а не передачи! и не взаимодействия!) успешно решают, просто использование и разработка были бы в разы удобнее, если несколько формализовать это дело. Например, создав табличку с динамическим добавлением и удалением из нее источника данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 00:29 |
|
Параметризовать в функции название связанного сервера
|
|||
---|---|---|---|
#18+
авторче вы привязались именно к TVF? я уже писал об этом потому что уже существуют "некие глобальные хранимые" - недотроги , от которых все и крутится, вызывающие себе функции с возвратом таблиц данных с разных источников, вот они вполне очень трогательные . Так вот. Не надо ржать. Задачу решили сделать так, может и неожиданно, но вариант. И он тоже является в какой-то мере надежным и простым дедовским способом: ЦЛР решено не делать. Раз уж всё равно всё, что этим прожехом связано - работает исключительно на скриптах и перед запуском скриптов всё равно все скрипты проходят некий свой собственный препроцессор, его решили настроить так, что при отработке (в целом редкого) события "добавить новый источник данных" препроцессор каждый раз будет создавать уникальную функцию для получения данных из него. А в общую функцию получения данных из источников в нужное место вставляться код с вызовом этой уникальной функции. Минусы есть, но не критичные. Всё. Если вдруг кто-то предложит какой-то иной дельный вариант, конечно почитаю для пользы дела. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 01:22 |
|
|
start [/forum/topic.php?fid=46&msg=40014056&tid=1685463]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 292ms |
total: | 412ms |
0 / 0 |