Яндекс.Метрика
    Поиск по тегу

    нормализация данных


    Найдено: 2 записи

    humour

    Вершина нормализации данных: getGenders

    Так как Хабр в первую очередь посвящен сфере ИТ, думаю, у следующей истории найдется много поклонников.

    Не так давно нашей команде пришлось интегрироваться с внешней финансовой системой посредством веб-сервисов. Кроме всего прочего, внимание привлек метод с таинсвенным названием getGenders. Комментарий к методу звучал как "Справочник полов (sex). Странно, но их два..." (без шуток). Ситуация усугублялась еще и тем, что метод принимал на вход строковый параметр.

    После нескольких попыток вызова метода с разными значениями параметра ответ таки удалось получить:

       id  | name   | vid
    ----------------------
    500001 | MALE   | "1"
    500012 | FEMALE | "1"
    

    Наверное не только у меня на языке вертелось «Действительно странно, а почему их два?», потому как под стол упали все.

    Подозрительно длинные идентификаторы можно было объяснить тем, что часто веб-сервисы генерируются на основании результатов запросов к базе данных, а в ней мог использоваться какой-то общий sequence для нескольких таблиц. Но параметр vId не давал нам покоя...

    Квест по выяснению этого важного вопроса у представителей фин. учреждения был назначен на самого серьезного человека из команды. Все оказалось до безобразия просто: vId — это номер версии системы.

    Зачем это нужно нам так толком и не объяснили, ограничившись сухим «что-то для миграции». Но я не оставляю надежды хотя бы в далеком будущем пообщаться с проектировщиком базы данных, так как ни на минуту не сомневаюсь, что для представления справочника полов с учетом версии он использовал как минимум 2 таблицы...

    Если кому-то инетерсно, вот код интерфейса (анонимизированный):

    /**
      * Справочник полов (sex). Странно, но их два...
      *                        
      * @param vId
      * @return java.util.List<api.dictionary.soap.Genders>
      */
    @WebMethod(action = "ns:getGenders")
    @WebResult(name = "genders", targetNamespace = "...")
    @RequestWrapper(localName="getGenders", targetNamespace="...", className="api.dictionary.soap.GetGenders")
    @ResponseWrapper(localName="gendersList", targetNamespace="...", className="api.dictionary.soap.GendersList")
    public List<Genders> getGenders(@WebParam(name = "vId", targetNamespace = "...") String vId);
    

    Напишите в комментариях, а что интересного и таинственного встречали вы в своей работе.

    humour

    Вершина нормализации данных: getGenders

    Так как Хабр в первую очередь посвящен сфере ИТ, думаю, у следующей истории найдется много поклонников.

    Не так давно нашей команде пришлось интегрироваться с внешней финансовой системой посредством веб-сервисов. Кроме всего прочего, внимание привлек метод с таинсвенным названием getGenders. Комментарий к методу звучал как "Справочник полов (sex). Странно, но их два..." (без шуток). Ситуация усугублялась еще и тем, что метод принимал на вход строковый параметр.

    После нескольких попыток вызова метода с разными значениями параметра ответ таки удалось получить:

       id  | name   | vid
    ----------------------
    500001 | MALE   | "1"
    500012 | FEMALE | "1"
    

    Наверное не только у меня на языке вертелось «Действительно странно, а почему их два?», потому как под стол упали все.

    Подозрительно длинные идентификаторы можно было объяснить тем, что часто веб-сервисы генерируются на основании результатов запросов к базе данных, а в ней мог использоваться какой-то общий sequence для нескольких таблиц. Но параметр vId не давал нам покоя...

    Квест по выяснению этого важного вопроса у представителей фин. учреждения был назначен на самого серьезного человека из команды. Все оказалось до безобразия просто: vId — это номер версии системы.

    Зачем это нужно нам так толком и не объяснили, ограничившись сухим «что-то для миграции». Но я не оставляю надежды хотя бы в далеком будущем пообщаться с проектировщиком базы данных, так как ни на минуту не сомневаюсь, что для представления справочника полов с учетом версии он использовал как минимум 2 таблицы...

    Если кому-то инетерсно, вот код интерфейса (анонимизированный):

    /**
      * Справочник полов (sex). Странно, но их два...
      *                        
      * @param vId
      * @return java.util.List<api.dictionary.soap.Genders>
      */
    @WebMethod(action = "ns:getGenders")
    @WebResult(name = "genders", targetNamespace = "...")
    @RequestWrapper(localName="getGenders", targetNamespace="...", className="api.dictionary.soap.GetGenders")
    @ResponseWrapper(localName="gendersList", targetNamespace="...", className="api.dictionary.soap.GendersList")
    public List<Genders> getGenders(@WebParam(name = "vId", targetNamespace = "...") String vId);
    

    Напишите в комментариях, а что интересного и таинственного встречали вы в своей работе.