Есть один нюанс о котором редко упоминают. Если у вас 2 и более мониторов - часы будут только на основном. Оказывается это очень не удобно. Возможно не всем, но хотелось бы что бы починили
у вас немного устаревшая информация на самом деле :) VPN в Крыму давно "не надо" -- т.к. бОльшая часть провайдеров давно завернула трафик гугла и эпла в ВПН уже на "своем" уровне, а так же весь мобильный интернет имеет "выход" не в Крыму, и с него прекрасно всё работает.
Кстати это и произошло именно потому, что население в своем большинстве "не осилило" даже такую простую вещь как ВПН.
часто для крупных клиентов - нет. ибо не иметь крупного клиента в сторе - хуже для самой Apple, чем соблюдение неких "правил" которые по-сути только для "холопов".
по моим ощущениям профит есть. Однако заморачивался я с этим не столько что бы «улучшить», сколько попадается сотф который например вместо своего окна рисует «белый» (ну или черный) экран, есть нет нормальной поддержки 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 страницы того, что приведено в статье — еще хуже читалось бы.
Есть один нюанс о котором редко упоминают. Если у вас 2 и более мониторов - часы будут только на основном. Оказывается это очень не удобно. Возможно не всем, но хотелось бы что бы починили
у вас немного устаревшая информация на самом деле :)
VPN в Крыму давно "не надо" -- т.к. бОльшая часть провайдеров давно завернула трафик гугла и эпла в ВПН уже на "своем" уровне, а так же весь мобильный интернет имеет "выход" не в Крыму, и с него прекрасно всё работает.
Кстати это и произошло именно потому, что население в своем большинстве "не осилило" даже такую простую вещь как ВПН.
ох если бы два. онлайн падает начиная с катаклизма. после панд - еще активнее.
побуду кэпом: вероятно, имелась ввиду таки авторизация.
часто для крупных клиентов - нет. ибо не иметь крупного клиента в сторе - хуже для самой Apple, чем соблюдение неких "правил" которые по-сути только для "холопов".
сколько людей не читает дальше первого предложения :( и отвечают на него. А дальнейшего текста как будто не существует.
Как насчет выпуска кредиток без пластика? 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 страницы того, что приведено в статье — еще хуже читалось бы.