Comments 22
«Параллельно с этим в оффлайн режиме работала шина, которая скапливала данные со всех учреждений на единый центральный сервер. В шине были багги: она создавала дубли по первичному ключу и не все данные доходили.»
На этом остановился, дальше не читаю. Решил подождать второй редакции поста.
На этом остановился, дальше не читаю. Решил подождать второй редакции поста.
Статья не про сиквел, статья про то, как нельзя работать с данными.
Согласен… сталкивался с подобным в этих структурах. В некоторых все еще работает ПО написанное на Foxpro, Clipper, Paradox… для хранения используются dbf или еще что пострашнее типа Btrieve который развернут на… Novell Netware. И причем за «поддержку» платят шестизначные суммы. На вопрос «Зачем так?!» к одному «поддерживателю», получен был обычный ответ «Работает же! Кто придумал, 10 лет назад уволился. Переписывать дорого.». И когда нам нужно было прикрутить это к вебу, они сказали просто «API простое… вот вам доступ по RDP, запускаете вот этот bat'ник вот с такими параметрами, вот в этой папке появляется файл dbf, из него данные и берете». Ну и потом выяснилось что все русские данные хранятся в CP866, а на некоторых старых компах стоит keyrus, и ввиду этого в русских словах используются английские буквы типа: a, o, p, e, c и т.д. В общем тот еще квест был.
Статья то как раз про mssql, так как я специально показал неправильно спроектированную систему, которая разрослась и зашла в тупик, и то что в mssql есть инструменты которые помогают выйти даже из такой тупиковой ситуации.
>>Данный пример для случаев, когда система уже спроектирована, и переделать ее вряд ли получится.
А зачем переделывать? Что плохого в том что центральный сервер сам забирает данные с периферийных? По-моему идеальный вариант.
А зачем переделывать? Что плохого в том что центральный сервер сам забирает данные с периферийных? По-моему идеальный вариант.
На самом деле это не очень хорошо, объем данных был большой и каждый раз их тащить по сети это не правильно. Кроме того министерство могло попросить сделать какой нибудь отчет срочно, и если какой нибудь сервер был недоступен на момент получения, в нем были бы не верные цифры, да и пользователю ждать получение данных с сотни разных серверов не очень хорошо. В общем это больше от безысходности подход.
Я работал web программистом в информационном центре одного из министерств с около сотней подведомственных учреждений. В каждом подведомственном учреждении на сервере была установлена десктоп программа, написанная на delphi, в которую ежедневно вносились данные. Раз в квартал каждому такому учреждению нужно было выгрузить dbf файл, приехать к нам в центр, по данным этой выгрузки получить отчеты и сдать их в министерство. Так было еще в досовской программе, а потом этот алгоритм просто ничего не меняя, перенесли в delphi. Выгрузка осуществлялась средствами Transact-SQL, и логика в ней была не простая.
Расскажу-ка я тоже одну историю. Все совпадения случайны и скорее всего вымышлены.
Одно министерство как-то заказало большой фирме, где я работал, Систему по оффлайновому сбору данных с подведомственных учреждений — набивка в dbf, перенос на диске в центр, загрузка в центральное хранилище. Продажа заказа была без моего участия, а когда его довели до меня, оказалось, что продали с реализацией на MS DTS. Типа там картинки, окошки, диаграмки потоков и преобразования данных, нажал кнопку и готово.
Стал я рисовать эти диаграмки, красиво, конечно. Но вот когда по этим диаграмкам создалось приложение и оно начало данные копировать, оказалось, что приложение сгенерировано на Visual Basic, огромное количество кода, а данные копирует оно по записям — прочитало запись в dbf, чего-то там подумало, записало в БД, опять подумало. То есть работало оно не просто медленно, а бесконечно долго, результата просто не дождешься, хотя данных там раз плюнуть, весь dbf в памяти помещался. Ковырялся я с этим неделю-две, уже не помню сколько, давно дело было, пакетной обработки не обнаружил, плюнул, и переписал на Delphi, получилась пара форм, один data module, и все летает. Ну диаграмок нет.
К сдаче проекта в министерстве начальство сказало распечатать (да-да, на бумаге) сгенеренные исходники на VB, потому что их было больше. Исходников на Delphi было-то всего ничего, не солидно как-то. И вот, сдача — в кабинете замминистра собралась толпа народу, все, кроме Самого, стоят, и куратор проекта со стороны заказчика, положа руку на папку с исходниками, говорит «Как видите, работа проделана большая...»
Кошмар, связанные сервера в 2018 году это просто жесть. Их использование чуть ли не совбез ООН запретил.
А что делать… используем, правда не в такой схеме, как у ТС
да иногда нет возможности выбирать
вопрос то не в том, что оон разрешил или запретил. Была система которая зашла в тупик из за того что она была не правильно спроектирована, связанный сервер это наверное единственное что там могло помочь. Никто не застрахован, что его могут перебросить на какой нибудь проект который писался еще при советской власти не понятно кем и как, в котором придется хоть как то но решать задачу.
в случае если данные есть только на продуктивном сервере
Видимо есть ещё малопродуктивный и совсем непродуктивный серверы?
А вообще становится сильно грустно от прочтения подобных статей — если на ключевые точки контроля сбора отчётности в министерствах ставят ответственных ит-специалистов, которые не знают основных возможностей sql-сервера в плане администрирования, а узнают об этом только погуглив, то всё очень плохо.
Это не претензия к автору, он то как раз молодец, поднял свой уровень знаний, а претензия к его руководству. Такие вещи делаются не на боевых серверах и не в авральном режиме.
А что не так с продуктивом?
продуктивный сервер. совсем не режет глаз?
Нет. У нас тысячи таких. Так и называем. И все называют. Прод и продуктив.
Вы разницы между словами «продуктивный» и «прод», «продуктив» не замечаете? В первом случае — это неправильный перевод термина, а в вашем случае — это слэнг, перевод слова production. Давайте тогда введём в оборот все варианты перевода product — продуктовый, плодовый, результативный, а потом удивляться почему ракеты падают.
Да там все делалось в авральном режиме, постоянно весело несколько сотен актуальных необработанных обращений от пользователей. Начальник кстати когда понял, что отмахнуться по легкому не получиться сбежал взяв две недели отпуска и потом три больничного, в общем на весь период сдачи отчета. По поводу «если на ключевые точки контроля сбора отчётности в министерствах ставят ответственных ит-специалистов, которые не знают основных возможностей sql-сервера» — да там даже студенты не задерживали, сами посудите на организацию которая занимается аналитикой, статистикой и разработкой ПО всего 5 пишущих программистов и среди этих пяти текучка бешеная.
Мне понравилась статья, потому, что автор достиг просветления, постигнув дзен разработки в крупной компании/организации. Со временем я верен он обязательно достигнет уровня мастера (начальника отдела). И это не ирония
Sign up to leave a comment.
MSSQL Server. Пример применения связанного сервера