Поправил, данные большого объема пересылаются частями также как и файлы, размер части зависит от настройки filepartsize.
В статье приведен пример подключения клиента, код сервера открыт, если вам что то не нравится вы всегда можете переписать как вам угодно.
Возможно сам пока не сталкивался, около 20 пользователей и комнат + несколько тысяч сообщений проблем не создают. О возможной проблеме в будущем знал, поправить несложно.
Подразумевалось что перечеркнут, инвентарный номер написанный от руки.
Как такое лучше изобразить дабы никого не пугать не знаю.
Корпус хороший тоже дома мини сервер радует.
В предыдущем своем ответе, я не писал что они используют именно NFC. В самом начале статьи написано про то что технологии со временем становятся доступней и про дорогие ТСД.
Статья оригинал не такая свежая.
Slack не пользуюсь, часто запущен Whatsapp десктоп, диспетчер задач постоянно на втором мониторе, потребления ресурсов Whatsapp не замечал, 300мб памяти занимает, соглашусь не мало. Также есть свое приложение на electron, нагрузки на процессор в свернутом режиме в фоне, тоже не замечал, памяти всего 111мб.
Также пользуюсь VS code, там порой видна в фоне какая то нагрузка, периодически бывает до 10%, но это совсем другое приложение.
Упоминал в статье, пользуюсь встроенным adblock. Не скажу в adblock что все устраивает, настроек не так много.
Видел несколько статей о небезопасности расширений. Вот последняя https://habr.com/post/421735/. В какой то из них видел утверждение что самое безопасное свое.
В моем велосипеде нет привязки к конкретным тегам и классам, весь сто строк с лишним.
Переименование таблицы и или поля также требует изменения связанных запросов.
Такое переименование в теории может вообще все поломать.
Описанное решение не является анаЛогом RECOVERY из MS SQL, и не предназначено для хранения истории записей всей базы.
1. Цель статьи в заголовке, описание простого примера.
2. Возможно
3. Записи историю которых предполагается сохранять, изменяются как правило по одной. В статье нет призывов сохранять версии абсолютно всех записей, базы данных.
4. В пунктах 2, 3 описаны примеры как избежать возможного overhead-a. А здесь похоже наоборот, почему?
5. По вашей ссылке, похожа только таблица версий, но она значительно сложнее.
На лавры изобретателя «версионирования записей» не претендую. В самом начале статьи описан вариант с XML, но там было много кода и несколько дополнительных запросов. Таблица можно сказать взята оттуда.
1 — 4 Вполне возможно.
5. По моей ссылке с полным примером, видно что PostgreSQL использовался 9.6.9, а «автопартицированные таблицы» появились только в 10 версии. Не знаю насколько хорошо, индексируются слайды pdf, может быть плохо искал.
В статье приведен пример подключения клиента, код сервера открыт, если вам что то не нравится вы всегда можете переписать как вам угодно.
Я еще в коде иногда var пишу.
Возможно сам пока не сталкивался, около 20 пользователей и комнат + несколько тысяч сообщений проблем не создают. О возможной проблеме в будущем знал, поправить несложно.
Как такое лучше изобразить дабы никого не пугать не знаю.
Корпус хороший тоже дома мини сервер радует.
Slack не пользуюсь, часто запущен Whatsapp десктоп, диспетчер задач постоянно на втором мониторе, потребления ресурсов Whatsapp не замечал, 300мб памяти занимает, соглашусь не мало. Также есть свое приложение на electron, нагрузки на процессор в свернутом режиме в фоне, тоже не замечал, памяти всего 111мб.
Также пользуюсь VS code, там порой видна в фоне какая то нагрузка, периодически бывает до 10%, но это совсем другое приложение.
Видимо неспроста в раннем творчестве упоминается «couchDB» созвучное слову «coach».
Видел несколько статей о небезопасности расширений. Вот последняя https://habr.com/post/421735/. В какой то из них видел утверждение что самое безопасное свое.
В моем велосипеде нет привязки к конкретным тегам и классам, весь сто строк с лишним.
Такое переименование в теории может вообще все поломать.
Описанное решение не является анаЛогом RECOVERY из MS SQL, и не предназначено для хранения истории записей всей базы.
Делал давно точно не вспомню, для примера согласен надо было упростить.
2. Возможно
3. Записи историю которых предполагается сохранять, изменяются как правило по одной. В статье нет призывов сохранять версии абсолютно всех записей, базы данных.
4. В пунктах 2, 3 описаны примеры как избежать возможного overhead-a. А здесь похоже наоборот, почему?
5. По вашей ссылке, похожа только таблица версий, но она значительно сложнее.
На лавры изобретателя «версионирования записей» не претендую. В самом начале статьи описан вариант с XML, но там было много кода и несколько дополнительных запросов. Таблица можно сказать взята оттуда.
5. По моей ссылке с полным примером, видно что PostgreSQL использовался 9.6.9, а «автопартицированные таблицы» появились только в 10 версии. Не знаю насколько хорошо, индексируются слайды pdf, может быть плохо искал.
Ничего похожего не нашел, решил поделиться.