Как же заколебали современные сайты - где "сочные, яркие" картинки довольных людей всех национальностей, которые улыбаются, жмут друг-другу руки, дружески подсказывают и т.п., а техническая информация заныкана так, что даташиты на железки (с этого сайта) приходится искать с помощью гугла. Мне определенно нравится подход китайцев!
Проверил на Majestic Million CSV, который исходно весит 77мб. SQLite файл с импортированной таблицей - 72мб, json при кодировании "в лоб" [{"column1": "value1", "column2": "value2", ...}, ...] - 230мб. Однако, при передаче файла скорее всего будет использоваться gzip и тут уже не все так однозначно - sqlite ужимается до 31мб, а json до 34мб, то есть разница несущественна. В целом результат предсказуем, т.к. sqlite по умолчанию не использует архивацию данных (хотя есть расширения для этого), т.е. экономия места идет в основном за счет хранения чисел.
Насколько быстр будет поиск - зависит от того, что именно надо искать и как хранить данные. Если в json хранить строки не в виде массива, а в виде объекта, где id строки - это ключи объекта, то получение данных по id у json будет быстрее. Если надо фильтровать по текстовым полям, то sqlite может получить преимущество за счет использования индексов, но есть подводный камень: скорее всего будет использоваться один индекс из-за особенностей планировщика SQLite, т.е. при фильтрации по одной колонке с индексом SQLite будет быстрее, при участии нескольких - уже не факт.
Имхо, все справочники должны храниться на сервере и отдавать результаты по API. Вариант с загрузкой базы на клиент выглядит каким то костылем. Может в Битрикс так принято, не знаю.
Очень сомнительное решение для любой задачи. Выгоды перед обычным json-файлом - нет. Какие то хитрые выборки из справочников, требующие SQL, едва ли требуются на клиенте. Получается использование технологии ради технологии.
P.S. В SQLite нет типа данных date и такие данные хранятся как текст, поэтому scheduled_departure > "2017-07-18" работать будет (при использовании формата YYYY-MM-DD обычная сортировка строк подходит), но лучше использовать дату в UTC (int).
И да, для строковых литералов, рекомендуется использовать одинарные кавычки scheduled_departure > '2017-07-18'. Двойные - для идентификаторов, напр. имен колонок или таблиц. При компиляции есть даже специальный флаг SQLITE_DQS, запрещающий использование двойных кавычек для строк, но он по умолчанию неактивен.
Вам реклама, а мне на удивление как раз во время :)
Тут у меня объект типа школа нарисовался и нужно сделать "белый интернет" (с 2023 г. им нужно все школы оснастить), а как он реализуется, что-то нигде не нашел. Я просто от сетей немного далек и честно думал что делается это сертифицированной железкой (в 2014 году видал такую в стеке на базе серваков - подозреваю что это был pfsense).
Или есть что-то более актуальное? NGFW просто каких-то хороших денег стоят.
PS С сайта:
Офис в Москве:
Россия, 141009, Московская обл., г. Мытищи ул. Ак. Каргина, 34-95.
Вы в музей бесплатно ходите? Да и пазлы наверное не на помойке нашли? Купили - наслаждайтесь, работайте лучше, чтобы купить иные вариации этой замечательной картины :)
Как начинающий (изучающий), могу добавить - да это пипец: скорость изменения инструментария 2 года. Начинаешь изучать одно, а тут уже свежатинка подъехала (пример).
Имея небольшой опыт взаимодействия с эксплуатацией промышленных и административных объектов, могу написать следующее:
30-лет отпахавший "Петрович" не просто так не хочет делиться своими знаниями - это залог того что его не уволят, а также не будут сильно напрягать. Это больше характерно для госкомпаний;
уровень эксплуатации начинается от кручения и заканчивается зачастую там же, все что более-менее сложное делают подрядчики, которые выбираются иногда либо по цене либо по назначению сверху (сговор). Также встречал службу эксплуатации, которая не знала, что у них там на мониторах АСУ отображается.
имеющая документация зачастую не отражает текущее состояние объекта (даже на относительно новых), так как изготовление исполнительной документации - это ад: всем нужно быстрее закрывать объект (так как без этого денег не заплатят), уже все переругались, монтажники не помнят, что делали месяц назад, а стройка идет уже год и т.п. А нет исполнительной документации - считайте ничего нет.
А вы тут БИМ, ТИМ... Редко встречал объекты (хотя бывало), где все было как надо. Эксплуатация - это же расходная статья, зачем туда денег вливать?
Почти, только сделают через 4 месяца.
Я гдето похожее видел
Как же заколебали современные сайты - где "сочные, яркие" картинки довольных людей всех национальностей, которые улыбаются, жмут друг-другу руки, дружески подсказывают и т.п., а техническая информация заныкана так, что даташиты на железки (с этого сайта) приходится искать с помощью гугла. Мне определенно нравится подход китайцев!
Проверил на Majestic Million CSV, который исходно весит 77мб. SQLite файл с импортированной таблицей - 72мб, json при кодировании "в лоб" [{"column1": "value1", "column2": "value2", ...}, ...] - 230мб. Однако, при передаче файла скорее всего будет использоваться gzip и тут уже не все так однозначно - sqlite ужимается до 31мб, а json до 34мб, то есть разница несущественна. В целом результат предсказуем, т.к. sqlite по умолчанию не использует архивацию данных (хотя есть расширения для этого), т.е. экономия места идет в основном за счет хранения чисел.
Насколько быстр будет поиск - зависит от того, что именно надо искать и как хранить данные. Если в json хранить строки не в виде массива, а в виде объекта, где id строки - это ключи объекта, то получение данных по id у json будет быстрее. Если надо фильтровать по текстовым полям, то sqlite может получить преимущество за счет использования индексов, но есть подводный камень: скорее всего будет использоваться один индекс из-за особенностей планировщика SQLite, т.е. при фильтрации по одной колонке с индексом SQLite будет быстрее, при участии нескольких - уже не факт.
Имхо, все справочники должны храниться на сервере и отдавать результаты по API. Вариант с загрузкой базы на клиент выглядит каким то костылем. Может в Битрикс так принято, не знаю.
Очень сомнительное решение для любой задачи. Выгоды перед обычным json-файлом - нет. Какие то хитрые выборки из справочников, требующие SQL, едва ли требуются на клиенте. Получается использование технологии ради технологии.
P.S. В SQLite нет типа данных date и такие данные хранятся как текст, поэтому
scheduled_departure > "2017-07-18"работать будет (при использовании формата YYYY-MM-DD обычная сортировка строк подходит), но лучше использовать дату в UTC (int).И да, для строковых литералов, рекомендуется использовать одинарные кавычки
scheduled_departure > '2017-07-18'. Двойные - для идентификаторов, напр. имен колонок или таблиц. При компиляции есть даже специальный флаг SQLITE_DQS, запрещающий использование двойных кавычек для строк, но он по умолчанию неактивен.Кажется вам переезжать раньше надо было, лет эдак 5-10 :)
Можно было бы упомянуть и конкурента - OpenLayers.
Примерно аналогичная ситуация. За последние полгода сделал 3 заказа - все привезли с опозданием 3-5 дней. С - Сервис Сбера!
Планируется... Да когда не про планы начнут рассказывать, а про то что сделано?
Такс ждем продолжения для игры в царя горы :)
Имхо, камерам в санузлах не место (от взлома устройств никто не защищен).
Не удивлюсь, что из дружественного Китая уже едут волшебные наклейки, которые "басурманское оборудование" магически превращают в отечественное.
Стартапы в России не порожденные госухой и крупняком продолжают появляться?
Вам реклама, а мне на удивление как раз во время :)
Тут у меня объект типа школа нарисовался и нужно сделать "белый интернет" (с 2023 г. им нужно все школы оснастить), а как он реализуется, что-то нигде не нашел. Я просто от сетей немного далек и честно думал что делается это сертифицированной железкой (в 2014 году видал такую в стеке на базе серваков - подозреваю что это был pfsense).
Или есть что-то более актуальное? NGFW просто каких-то хороших денег стоят.
PS С сайта:
:)
Так вот как мыслил создатель BaldenOS: а нефига выкладывать опенсорс!
Вы в музей бесплатно ходите? Да и пазлы наверное не на помойке нашли? Купили - наслаждайтесь, работайте лучше, чтобы купить иные вариации этой замечательной картины :)
Военные смогут летать, а больше им пока и не нужно. Имхо.
Читал-читал, так и не понял какой посыл статьи или вас заставили что-нибудь налабать в корпоративный бложик?
Хм, что-то тут не так.
Как начинающий (изучающий), могу добавить - да это пипец: скорость изменения инструментария 2 года. Начинаешь изучать одно, а тут уже свежатинка подъехала (пример).
Имея небольшой опыт взаимодействия с эксплуатацией промышленных и административных объектов, могу написать следующее:
30-лет отпахавший "Петрович" не просто так не хочет делиться своими знаниями - это залог того что его не уволят, а также не будут сильно напрягать. Это больше характерно для госкомпаний;
уровень эксплуатации начинается от кручения и заканчивается зачастую там же, все что более-менее сложное делают подрядчики, которые выбираются иногда либо по цене либо по назначению сверху (сговор). Также встречал службу эксплуатации, которая не знала, что у них там на мониторах АСУ отображается.
имеющая документация зачастую не отражает текущее состояние объекта (даже на относительно новых), так как изготовление исполнительной документации - это ад: всем нужно быстрее закрывать объект (так как без этого денег не заплатят), уже все переругались, монтажники не помнят, что делали месяц назад, а стройка идет уже год и т.п. А нет исполнительной документации - считайте ничего нет.
А вы тут БИМ, ТИМ... Редко встречал объекты (хотя бывало), где все было как надо. Эксплуатация - это же расходная статья, зачем туда денег вливать?