Задать вопрос

vyegorov

Лайки

  • Где ошибка в запросе sql?

    @iamnothing
    Если у вас вот так будут записи:
    SELECT op.parcel_cn, op.id
FROM objects_process AS op 
WHERE op.status IS NULL

    И вот так будут записи:
    SELECT op.parcel_cn, op.id, o.area_value 
FROM objects_process AS op 
JOIN objects_copy AS o 
  ON op.parcel_cn = o.parcel_cn

    То значит, что у вас пустое множество строк при пересечении двух условий:
    ON op.parcel_cn = o.parcel_cn и
    WHERE op.status IS NULL т.е. нет таких записей, которые бы удовлетворяли сразу обоим условиям
    Ответ написан
    3 комментария
    3 комментария

  • Каков правильный способ хранения данных для этого случая?

    gwer
    @gwer
    Так и не понял, почему JSON — в PostgreSQL, а если без JSON, то MySQL, ну да не суть.

    В принципе, JSON или просто таблицы — тут уж как удобнее будет. На входе и на выходе одно и то же. На мой взгляд, лучше хранить правильно структурированные данные в БД. А с JSON работать по необходимости уже, не думаю, что проблемой станет туда-сюда конвертировать.

    А вот от колонок для каждого стиля, наверное, стоит избавиться. Какие-то стили необязательны, какие-то для отдельных объектов только — зачем избыточность? Можно иметь таблицу объектов, таблицу свойств. А стили хранить в связующей таблице со столбцами: id объекта, id свойства, значение свойства.

    За основу для свойств удобно должно быть взять CSS. Многим знакомые правила, вполне логичная система. Уже есть все методы хранения параметров текста, включая интерлиньяж и кернинг. Придумывать своего придется совсем немного.

    Что касается координат. Можно сделать привязку к левому и верхнему краям, задавать, соответственно, X и Y. Можно помимо X и Y еще задавать, грубо говоря, точку начала отсчета. Скажем, по умолчанию это левый верхний угол, но если мы задаем свойство, определяющее точку отсчета, как right-bottom, то объект будет расположен так, что нижний правый угол будет сдвинут на X и Y от нижнего правого угла объекта, относительно которого происходит позиционирование.

    Принципы позиционирования тоже из CSS можно взять, те же absolute и relative.

    Если обобщить, то вам нужно сделать свой HTML+CSS с блэкджеком и хранением стилей в БД. Отталкивайтесь от этого (=
    Ответ написан
    4 комментария
    4 комментария

  • Выбрать СУБД между MySQL, PostgreSQL, MariaDB и MSSQL?

    EugeneOZ
    @EugeneOZ
    Шардится и реплицируется Postgre проще и надёжнее. Но даже с учётом PDO, есть разница местами в синтаксисе и возможностях между ней и MySQL.
    Главное — не вляпайтесь в MSSQL. С ним можно нормально работать только внутри стека MS-инструментов. Оно даже UTF-8 не поддерживает. Ну и MS кладёт болт на не-виндовые драйвера, выпускают их очень редко.
    Ответ написан
    7 комментариев
    7 комментариев

  • Прокси-сервер с логированием пользовательских запросов

    @cat_crash
    Логгируйте в файлы CSV (http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html). Из CSV сам постгрес умеет сохранять в таблицы. Выделите отдельный ЛОГ сервер (Postgres) куда будут стекаться все логи.
    Профит
    Ответ написан
    1 комментарий
    1 комментарий

  • Как сделать быстрый полнотекстовый поиск?

    @hell
    Вообще говоря, встроенный в PostgreSQL полнотекстовый поиск работает весьма шустро. То еть, тормозов при граничных условиях поиска по 1000000 документам (объем каждого — от 1000 до 300000 символов, средний объем документа — 2000 символов) вообще говоря не наблюдается. Во всяком случае, на выделенном сервере (в данном конкретном случае используется Hetzner с 24Gb памяти, из них PostgreSQL кушает примерно четверть, версия PostgreSQL — 9.2 — на более ранних версиях результаты были немного другими.)
    Я бы рекомендовал попробовать протестировать вашу текущую конфигурацию на производительность с разными движками. И, в случае использования постгреса, не использовать подсветку результатов.
    Ответ написан
    Комментировать
    Комментировать