по моим ощущениям профит есть. Однако заморачивался я с этим не столько что бы «улучшить», сколько попадается сотф который например вместо своего окна рисует «белый» (ну или черный) экран, есть нет нормальной поддержки OGL или DX. С RemoteFX такие артефакты сошли на нет.
— Одна таблица на структуру данных. Нельзя сделать таблицу deleted_users и перемещать туда удаленных пользователей с сохранением всех связей по id с другими таблицами, надо делать поле is_deleted и учитывать его во всех запросах.
вот прям сейчас смотрю на проекте именно на реализацию с deleted users… и если честно, лучше б это было поле is_deleted. А зачем его учитывать? Сделайте view ActiveUsers по условию not deleted да и все? Любой из этих вариантов жизнеспособен. Какой — выбирать вам :-) Еще раз. Язык запросов тут не причем.
— Джойн для получения данных связанной сущности это вообще неоптимальная вещь. У нас есть одна статья и много комментариев, и чтобы получить статью с комментариями, надо сделать джойн с таблицей комментариев, и в результате будет куча копий строки из таблицы статей.
Можно делать и не так. Оптимально ли? Зависит от приложения.
table_a JOIN table_user USING(fk_user)
Согласен, выглядит «стильно» — но зачем? Не читаемо абсолютно. Кто его знает что там за фк у вас. а если он составной… и его название выглядит как FK_scheme_table_field1_scheme_table_field2_on_scheme_table2_field1_scheme_table2_field2 (утрировано конечно) то назвать это более читаемым что то я не могу. А сокращенное название никак не даст представление о том, что там. Откуда привычка экономить буквы? Вы же не стели бы читать статью в которой все слова написаны сокращениями? Зачем?
Простите, но если с пунктом номер два еще можно согласиться (действительно, полотна на 2-3 «страницы» бывает читать сложно, однако их надобность — тема отдельного разговора), то п.1 — а причем тут собственно язык? Оптимизация запроса (всмысле выбора плана и «ниже») — целиком и полностью ответственность СУБД, вы можете ей лишь «подсказать» уточнив вопрос до более адекватного. Я например был бы очень против внедрения в запрос каких-то ключей/аттрибутов для управления оптимизацией запросов. Ну это выглядит как ужасный костыль. Неужели вам и правда такое требуется? Может тогда дело не в языке, а к примеру в архитектуре приложения?
насчет тестирования наверное нужен пример. я не очень понял суть проблемы.
ПС: Если честно, полотно в 2 страницы того, что приведено в статье — еще хуже читалось бы.
так у вас и не 4К по сути, а обычные FHD (из-за масштабирования в 200%), что на 15 дюймах конечно же достаточно заметно при отключенном сглаживании то. А вот на нормальном разрешении (при отключенном масштабировании) вы уже врядли заметите «лесенки» как верно подметил nixtonixto
Я это прекрасно понимаю. И всеравно мнение свое не поменяю :) Плюс у меня был тариф 30мбит/сек CIR100% — и это куда лучше чем «виртуальные» 100мбит — хотя и заметно дороже. Во всяком случае в таком раскладе у тебя етсь права, и провайдер, кстати, куда охотнее принимает меры если что то не так. Ибо контракт без всяких «до».
да, несомненно, но тогда давали бы конкретные формулировки (как со SLA). Например, жестко зафиксировать минимально допустимую скорость с роутера до выходного узла провайдера…
Кстати, у нормальных провайдеров часто есть тарифы с CIR… Типо 100мбит CIR50%. Правда доступны они чаще для «юриков», чем для «физиков» — но, в целом, вы могли бы заказать такой тариф (если провайдер предоставляет). Но его стоимость будет выше.
да и с проф. аудио тоже все плохо очень. Не интересен он (линукс) крупным игрокам. Как раз (имхо) из-за зоопарка систем / ядер / и т.п. Нереально весь этот бардак поддерживать.
сколько людей не читает дальше первого предложения :( и отвечают на него. А дальнейшего текста как будто не существует.
Как насчет выпуска кредиток без пластика? 2021 год в конце концов!
А как насчет не торговать персональными данными? Мечты, мечты...
но это не «прокидывание» GPU в виртуалку… и «поиграть» по сути не получится.
вот прям сейчас смотрю на проекте именно на реализацию с deleted users… и если честно, лучше б это было поле is_deleted. А зачем его учитывать? Сделайте view ActiveUsers по условию not deleted да и все? Любой из этих вариантов жизнеспособен. Какой — выбирать вам :-) Еще раз. Язык запросов тут не причем.
Можно делать и не так. Оптимально ли? Зависит от приложения.
Согласен, выглядит «стильно» — но зачем? Не читаемо абсолютно. Кто его знает что там за фк у вас. а если он составной… и его название выглядит как FK_scheme_table_field1_scheme_table_field2_on_scheme_table2_field1_scheme_table2_field2 (утрировано конечно) то назвать это более читаемым что то я не могу. А сокращенное название никак не даст представление о том, что там. Откуда привычка экономить буквы? Вы же не стели бы читать статью в которой все слова написаны сокращениями? Зачем?
насчет тестирования наверное нужен пример. я не очень понял суть проблемы.
ПС: Если честно, полотно в 2 страницы того, что приведено в статье — еще хуже читалось бы.
Кстати, у нормальных провайдеров часто есть тарифы с CIR… Типо 100мбит CIR50%. Правда доступны они чаще для «юриков», чем для «физиков» — но, в целом, вы могли бы заказать такой тариф (если провайдер предоставляет). Но его стоимость будет выше.
А вообще, было бы круто, что бы законом запретили oversell провайдерам… Но это фантастика :)