Вы кажется не осознали всю боль. Откройте пример play.golang.org/p/TNfS7eyYSf и сотрите фигурные скобки, которые задают новую область видимости.
Код скомпилируется, несмотря на повторное :=
А вот если еще объявить var err error перед этим, то получим уже
А материализованные представления используют тот же принцип хранения?
Мне кажется было бы интересно держать таблицу в привычном виде, и иметь возможность создавать к ней несколько автообновляемых кластеризованных материальных представлений. Хотя может я думаю не в том направлении)
Как по Вашему, является ли серьезным недостатком PostgreSQL отсутствие кластерных индексов?
На этом сайте написано что они есть в планах. Не знаете случайно, как долго ждать?)
Да, вертика — это все-таки OLAP а не OLTP, и частые мелкие инсерты вызывают внутренние процессы по перестройке ROS контейнеров, что может сказаться на производительности всего кластера.
Поэтому лучше где-то буферизировать и пачкой записывать сразу в ROS.
Я как разработчик myshows скажу что мы нацелены не на расчет часов, а на учет просмотренных серий. Расчет потраченного времени — просто дополнительный бонус.
Приложение конечно красивое, но мне кажется толку от него никакого. Похоже на истерию вокруг приложения been — неделю оно было популярно, больше его не видно.
Вы пизданулись что ли все? Кто эти люди кто добавил статью в избранное? Вы хотите открыть что-то новое для себя в повторном чтении этих обычных запросов?
Очень хотелось заценить Швейцарию. Перелеты из Питера, ДС и Финки оказались неадекватными.
А у вас на карте нашли рейс «туда» из Лаппеенранты в Берлин и обратный из Франкфурта с такими датами и ценами, что можем доехать до Цюриха, и в сумме выходит классная цена!
Вот только что хотелось бы точно — поиск обратного рейса сразу на карте.
Т.е. я вот знаю, что хочу попасть в центральную Европу в середине августа из Лаппеенранты, а потом в конце августа тоже из центральной обратно. Типа обратный поиск, зная только точку назначения. Хоть в платный аккаунт это выносите — будет пользоваться спросом)
У нас с коллегами есть свой php фреймворк.
Так вот там мы реализовали деревья следующим образом.
Для каждого дерева ведется две таблицы: таблица самих данных и таблица структуры.
Таблица данных не хранит никаких сведений об отношениях между записями.
Таблица же структуры хранит:
1. parented (как я понимаю одного его достаточно для написания рекурсивного запроса)
2. ltree поле «path»
3. rKey и lKey для Nested Sets
Таким образом, если мы делаем продукт на PostgreSQL, мы пользуемся ltree, иначе – другими средствами. И переход с одной СУБД на другую осуществляется без проблем.
Иногда меня посещали мысли о том, что, по сути, любую привычную таблицу можно свести к таблице из одного hstore поля, но все же что-то в нем не так.
Ведь это не альтернатива привычным типам данных, это просто «еще один тип», который позволяет совершать над ним специфичные операции. Т.е. это по сути тот же TEXT с более функциональным оператором LIKE.
А реляционная модель все же устанавливает конкретные связи между сущностями, и глядя на такую модель опытный человек может даже составить для себя представление о бизнес-процессах, для которых эта модель была составлена.
Мы, кстати, сделали новую версию API с OAuth и JSON-RPC и даже прикрутили к нему Swagger.
https://api.myshows.me/shared/doc/
Будут вопросы/предложения — пишите, с радостью ответим)
Код скомпилируется, несмотря на повторное :=
А вот если еще объявить var err error перед этим, то получим уже
no new variables on left side of :=А со скольки серверов?
Мне кажется было бы интересно держать таблицу в привычном виде, и иметь возможность создавать к ней несколько автообновляемых кластеризованных материальных представлений. Хотя может я думаю не в том направлении)
На этом сайте написано что они есть в планах. Не знаете случайно, как долго ждать?)
Поэтому лучше где-то буферизировать и пачкой записывать сразу в ROS.
Ну и делать UPDATE и DELETE тоже лучше не стоит.
Вертика отлично обрабатывает gzip и файл в 25млн строк заливается за ~30 сек
Дизайн менять будем, надеюсь очень скоро. Тормозов вроде сильных быть не должно.
У нас много идей как улучшить сервис, но поскольку это хобби и оно не приносит дохода — все выходит вот так медленно(
Приложение конечно красивое, но мне кажется толку от него никакого. Похоже на истерию вокруг приложения been — неделю оно было популярно, больше его не видно.
Очень хотелось заценить Швейцарию. Перелеты из Питера, ДС и Финки оказались неадекватными.
А у вас на карте нашли рейс «туда» из Лаппеенранты в Берлин и обратный из Франкфурта с такими датами и ценами, что можем доехать до Цюриха, и в сумме выходит классная цена!
Вот только что хотелось бы точно — поиск обратного рейса сразу на карте.
Т.е. я вот знаю, что хочу попасть в центральную Европу в середине августа из Лаппеенранты, а потом в конце августа тоже из центральной обратно. Типа обратный поиск, зная только точку назначения. Хоть в платный аккаунт это выносите — будет пользоваться спросом)
Вот пример запроса для карты
transport.orgp.spb.ru/cgi-bin/mapserv?TRANSPARENT=TRUE&FORMAT=image%2Fpng&LAYERS=vehicle_trolley&MAP=vehicle_typed.map&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A900913&_OLSALT=0.8096415703184903&BBOX=3369916.5668083,8373436.6405009,3395247.1864858,8388640.8826711&WIDTH=1294&HEIGHT=777
Вот по этому урлу
transport.orgp.spb.ru/cgi-bin/mapserv?1&MAP=vehicle_typed.map&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities
можно узнать конфиг карты
По идее, прочитав доку, можно найти метод, который вернет координаты точек, а не просто картинки слоев
Я пока составил такой запрос:
transport.orgp.spb.ru/cgi-bin/mapserv?1&LAYERS=vehicle_trolley&MAP=vehicle_typed.map&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&WIDTH=1294&HEIGHT=777&SRS=EPSG%3A900913&BBOX=3369916.5668083,8373436.6405009,3395247.1864858,8388640.8826711&QUERY_LAYERS=vehicle_trolley
Но он вернул «Requested layer(s) are not queryable»…
P.S. Парсер, не подведи
Так вот там мы реализовали деревья следующим образом.
Для каждого дерева ведется две таблицы: таблица самих данных и таблица структуры.
Таблица данных не хранит никаких сведений об отношениях между записями.
Таблица же структуры хранит:
1. parented (как я понимаю одного его достаточно для написания рекурсивного запроса)
2. ltree поле «path»
3. rKey и lKey для Nested Sets
Таким образом, если мы делаем продукт на PostgreSQL, мы пользуемся ltree, иначе – другими средствами. И переход с одной СУБД на другую осуществляется без проблем.
Ведь это не альтернатива привычным типам данных, это просто «еще один тип», который позволяет совершать над ним специфичные операции. Т.е. это по сути тот же TEXT с более функциональным оператором LIKE.
А реляционная модель все же устанавливает конкретные связи между сущностями, и глядя на такую модель опытный человек может даже составить для себя представление о бизнес-процессах, для которых эта модель была составлена.
Если hstore представляет собой банальное key-value поле, то window все же более интересен.