Pull to refresh
15
0
Send message

| Важно: для игры нужно использовать стрелки на цифровой клавиатуре.

Эх, на ноутбуке не поиграешь. Вспомнил детство так как писать в видео память и приходилось в первых собственных играх на ассемблере, поэтому код довольно понятен.

Планируется ли вывести быструю кнопку автосуммы как в Excel (используется буква сигма Σ) в облачной или настольной версии? Не стоит недооценивать её использование пользователями и при переходе на МойОфис это сразу замечают практически при любом уровне владения Excel. Предваряя стандартный ответ: как вставлять формулы я знаю.

В моей Микроше стоял тумблер, который при переключении делал его Радио-86РК. И можно было играть в игры с обоих типов компьютеров. Сделали его знакомые папы с работы, у которых были такие же компьютеры с переключением и ещё эксклюзивные игры, которые сами писали люди программисты и приносили друг другу. Часто игры-клоны с x86. Я тоже писал игры под Микрошу и не без успеха. Спустя много лет нашёл Микрошу, но не включился никак, разбираться не стал, так и лежит в другом городе где-то. Картриджа ПЗУ не было всё с кассет. Скачивал потом эмуляторы на Windows и поностальгировал немного.

Старинный принтер HP LaserJet 3050 запечатал дома по сети с ноутбков. Жаль было с ним расставаться так цена отпечатка без бумаги близка к 0 с перезаправленными картриджами, но думал, что насовсем отрубилась возможность печатать по сети у старичка, ан нет ещё поработает. Спасибо.

Прочитал про сброс планов автоматом у процедур если находится превышение показателей. Помогает сброс плана автоматический или есть проблемы?

Имели опыт работы с Positive Technologies, Group-IB и другими. Что могу сказать — профессионалы на стороне добра. Печально, что так ограничивают развитие компании, которая знает как бороться с проникновением в вашу инфраструктуру непрошенных гостей.
Спасибо за Ваши комментарии.
… но БД NOSQL появились несколько раньше, чем SQL

В статье написано про термин NoSQL. Он появился уже позже. en.wikipedia.org/wiki/NoSQL
Также несогласен в том, что хранение JSON/XML это великое благо…

Это не описано как благо, а как существующая реальность и фича СУБД. Нравится это или нет, но так есть. В реляционные БД их пишут, а потом ещё и строят поверх индексы JSON или XML.
Первое ограничение SQLite, которое описано в статье, что это персональная СУБД, не поддерживающая схему клиент-сервер. Обычно СУБД поддерживает тысячи коннектов от пользователей, сервисов. Это вообще библиотека, с которой программа компилируется и работает как часть приложения. Это главное, что отличает её от остальных, она для небольших БД отдельных приложений. Когда пишу код для SQLite, то иногда забываю закрывать DB Browser, где менял или смотрел структуры и запущенная программа ждёт пока не освободится БД. Данные хранятся в 1 файле. Нет процедур, которые хранятся в самой СУБД, нет настроек, прав доступа так как персональная… Много чего ещё, чем отличается от MySQL / MariaDB, PostgreSQL. Она просто другая. SQLite небольшого размера, легко используемая с базовым набором функционала работы с данными используя SQL.
Ммм, а почему вы так говорите, будто мастер1 станет писать меньше данных?

Чтобы не возникало недопонимания дополнил текст "… ваша БД не успевает записывать из-за общей нагрузки.". Обычно помимо нагрузки на запись есть ещё нагрузка на чтение.

Пример с прошлой недели, проект распределен по датацентрам (и шардинг там тоже есть) начинаются очереди сообщений на RabbitMQ, мониторинг Zabbix фиксирует повышение нагрузки на разных хостах одного датацентра. Часть сайтов через переключатель CDN переводится на другой хостинг, часть остаётся и уравновешивается нагрузка. Запись идёт в оба master, они синхронизируют изменения, которых не стало меньше, но проблем стало меньше, сайты не 500-ят.

Упоминание тысяч участвующих вызывает лишь улыбку. Вот PostgreSQL...

Фраза про open source проекты в целом, никакие конкретные СУБД не упоминаются. Если вспоминать про PostgreSQL, до 13 версии тоже наверняка был кто-то.
Согласен. Тот же Facebook как основную БД использует MySQL. Есть там и другие БД, но они вторичны. И далеко не всем реально нужны хайлоады. По своему опыту скажу, что миллиарды вызовов в день за мелкими порциями данных, сотню тысяч IOPS-ов ( особенно на SSD+NVME) переваривает RDBMS даже на 1 хосте, а ещё можно и шардировать. Но кэши нужны, и они вполне могут быть не на RDBMS.
Можно проектировать онлайн, например, в dbdiagram.io, сами создатели СУБД имеют инструменты типа Oracle SQL Developer Data Modeler, у MS есть в Management Studio, в MySQL в workbench, PostgreSQL имеет кучу бесплатных и кросс-платформенных. Специализированные инструменты умеют строить по текущей структуре схемы и деплоить после изменений. Если бесплатные чем-то не устраивают, то платных для всех топовых СУБД достаточно где есть free тариф с ограничением числа диаграмм и объектов на них.
Спасибо, Вам, за позитивный ответ! Если чем-то расстроил, то извиняюсь. Получился такой лонгрид, который быстро не прочитать. Текст честно загонял в Word на предмет глупых опечаток и прочего, модерацию пост на сайте проходил.
Спасибо за пожелание, возможно напишу ещё по вопросам к этой статье. Современные СУБД редко имеют ограничения в размерах или типах, которые бы останавливали их использование. Устаревшие и без обновлений актуальных, могут такое иметь. Тут больше вопрос для чего нужна БД исходя из этого и подбирается СУБД. Тот же SQLite имеет много ограничений и отсутствующих особенностей, но берёт простотой и компактностью для персональных нужд.
Мы не являемся законодателями мод в плане БД и облачных тоже, поэтому путь к преобладанию облачных БД из России у нас будет долгим и тернистым. Но так как в России могут принудительно крупные госкорпорации туда отправить, то этот сегмент перейдёт быстро. Если хранить данные будет дешевле и проще без существенных доработок уже существующего функционала, то бизнес сам решит посчитав деньги.
Мы не являемся законодателями мод в плане БД и облачных тоже, поэтому путь к преобладанию облачных БД из России у нас будет долгим и тернистым. Но так как в России могут принудительно крупные госкорпорации туда отправить, то этот сегмент перейдёт быстро. Если хранить данные будет дешевле и проще без существенных доработок уже существующего функционала, то бизнес сам решит посчитав деньги.
Да, можно считать, что на текущий момент MariaDB и MySQL примерно одинаковы по функционалу. MariaDB ветка того же проекта MySQL после поглощения его компанией Oracle. Заподозрив в попытке слить его детище Oracle основатель Майкл Видениус создал открытую MariaDB. Протоколы MariaDB полностью совместимы с MySQL, значит приложения работают также.
Snowflake как представитель облачного хранения и анализа данных имеет место быть и есть кто использует, но он не топ. Amazon RDS c ядрами известных СУБД MySQL, PostgreSQL, MariaDB плюс там же Oracle и MS SQL, а также MS Azure, Azure Cosmos DB, и множество типов специфичных AWS СУБД (https://aws.amazon.com/ru/products/databases/) — это то, куда чаще смотрят если хотят облачных БД.
Лучше сразу сказать, что это не OLTP СУБД, текущие операции бизнеса ей не поддержать, она для анализа накопленных больших данных и быстрого поиска в них. Когда интегрировали её в инфраструктуру на одном из проектов, то несколько багов открыл мой коллега, завёл в github-е issues. Нужно будет проверить всё ли пофиксили.)
Полагаю, что специалисты, например, использующие PostgreSQL (тоже OpenSource) могут с Вами поспорить насчёт реляционных. И реляционные БД живей всех живых, об этом было в статье.) Я использую MongoDB и знаком с ней с 2010 когда её с трудом можно было пользовать, чтобы прям вау не сказал бы, но улучшается с каждым годом и растёт не просто так, есть нужные особенности.

Information

Rating
Does not participate
Registered
Activity