Стоял примерно перед таким же выбором, и внезапно, решил попробовать макбук, который 12". Всего с одним usb-c портом и разъёмом 3.5мм под наушники. Выбор пал на машинку с core i5/8/256, которая заменила собой macbook pro 13" late 2013.
Ухудшения в производительности не заметил, примерно так же или быстрее (видимо за счёт более быстрого ssd). При том, что у меня всегда запущена виртуалка и ещё десяток приложений. Работаю за монитором с блютусной клавиатурой, ноут лежит рядом с закрытой крышкой.
Из плюсов: вес, время работы, производительность, возможность подключить к монитору один (!) кабель для видео, зарядки и аудио (чем я активно пользуюсь).
Из минусов: один разъём usb-c. Вынужден был поменять мышь (игровую логитек на логитек же, мх мастер 2эс).
А вот что сильно раздражает: когда думал про замену ноутбука, смотрел на мониторы с разъёмом usb-c. Разъём первый раз появился (в ноутбуках на рынке) около двух лет назад. А мониторов с диагональю 27" и более, на маркете, до сих пор, ровно 8 штук. Восемь! И кто стоит поперёк прогрессивных решений? При том, что это очень удобный вариант подключения, особенно, если в мониторе полноценный USB хаб.
Как ни странно, но продавцы помнят. У нас похожая схема в похожем бизнесе. Причём, так как продавцы считают, что все вышестоящие спят и видят, как бы их лишить бонусов, было решено показывать практически онлайн, кто, сколько и за что получил бонус. Все вопросы касаемо бонусов снялись.
Вот тоже за эти слова глаз зацепился. Вы либо можете измерить уровень, либо не можете. Как можно мерить учитывая фактор ускорения таяния вечных льдов?!
Вы кажется не совсем понимаете что такое клиентская часть
Вы мне кажется очень мало сталкивались с разработкой.
Вы могли бы, например, перестать оценивать что и насколько я понимаю, и с чем и в каких объёмах сталкивался, а? Спасибо.
Установка в поле «книг всего» значения (P.S делать так это бред, количество книг должно считаться всегда вызывая метод подсчёта в нужный момент...
Вот прям бред? Это потому, что вы не уверены в данных (вдруг их кто-то изменил), и хотите посчитать их динамически. А триггер, как раз эту уверенность даёт. Выражаясь в вашем стиле: это бред, считать динамически каждый раз, заведомо знаю, что ничего в таблице не поменялось.
И код подобный тому что у вас там написан сам сгенерируется и выполнится, ибо подобные задачи обыденные и разработчики фреймворков давно зашили всё это внутрь, чтоб не пришлось писать много кода постоянно.
Я, извините, категрически не верю, что фреймворк сгенерирует код триггера на изменение таблицы. Думаю там всё гораздо проще.
… но вы попробуйте что нибудь посложнее сделать, чем просто посчитать все книги, количество кода увеличиться в 10-ки раз если делать это на SQL
От того, что вы не видите SQL, не значит, что его нет, в итоге у вас и код фреймворка, и SQL, в котором вы разбираться не хотите, надеясь, что за вас напишут хорошо, красиво и быстро.
Написать посложнее я пробовал, получилось.В одной из сейчас работающих баз данных, 1400 хранимых процедур, большая часть, достаточно простая (CRUD), часть отчёты, часть совсем сложная (финансы, например), но оно работает и самодостаточно, приложение можно написать новое, а логика останется, хоть из командной строки работайте. Плюс на сервере сотня (100) linked server (в основном PostgreSQL), с которыми происходит постоянный обмен данными в обоих направлениях, и всё это (включая сотню постгресов) поддерживается мной. Времени именно на поддержку уходит мало, 1-2%. Я новое разрабатываю, а это живёт само.
Простота кода, дело привычки. Я считаю это простой архитектурой. Потому что в коде приложения будет только вызов процедуры.
Хотя ниже по ветке я _наконец-то_ увидел аргументы, в пользу не разрешать прямое подключение к серверу БД, если речь про веб. Видимо, в таком случае, бэкэнд должен вызывать хранимые процедуры перекладывая параметры один-в-один.
Вы, кажется, не совсем понимаете, что такое база данных. Это далеко не только хранилище, это ещё и хранимые процедуры, функции, триггеры. Которые заменяют backend написанный на PHP, и которым до данных гораздо ближе.
И вместо того, чтобы дёргать из десктопа за ручки API, написанного на PHP, в котором всё равно написаны SQL команды, я буду дёргать за те же ручки, написанные сразу на SQL.
Для добавления книги позовём процедуру добавления, что-то типа
EXECUTE Books_add @AuthorID=823, @BookTitle='Улитка на склоне';
А всё, что происходит помимо собственно добавления книги, например поле «книг всего» у автора, напишу в триггере для таблицы Books
CREATE TRIGGER tr_Books_insert
ON Books
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
UPDATE Authors SET
BooksTotal = COALESCE(BooksTotal,0) + (SELECT COUNT(a.AuthorID) FROM inserted a WHERE a.AuthorID = Authors.AuthorID)
WHERE Authors.AuthorID IN (SELECT a.AuthorID FROM inserted a)
С одной стороны да, с другой стороны, при достаточном опыте, уже хватает ума в такую жёсткую логику класть только то, что не имеет исключений.
p. s. Клуб анонимных любителей залезть в данные напрямую :-)
Я не говорю делать вычисления на клиенте, я говорю делать дополнительную прослойку на серверной стороне которая будет отделять клиентскую часть от базы данных. В ней и писать все вычисления.
Представьте, что такой частью является комплекс хранимых процедур, функций, триггеров. И скажите пожалуйста, что это за прокладка, с которой могут работать клиенты под разные платформы.
Это не совсем хорошая практика исправлять что-либо подключаясь напрямую к базе данных, для избежания каких-либо проблем используют такие вещи как «seed» к примеру, и с помощью этого инструментария и вносят изменения в БД.
Это отвратительная практика. Но мне очень спокойно, что при любом исходе я не буду разгребать отрывочные сведения по всем таблицам. Почему-то первичный ключ использовать можно, а триггер, который поддерживает мою логику нельзя.
Почему сразу веб-приложение? Пусть это будет много клиентских приложений, на нескольких платформах, в том числе и веб.
Откровенно неудобно писать одну и ту же логику на разных языках, с возможностью сделать ошибку в столько раз более вероятно, сколько языков используется.
В моём понимании, бизнес-логика, это нечто, что соблюдается очень жёстко. Следовательно, оно должно быть на уровне базы данных. То есть никто, даже случайно, не должен иметь возможность сделать данные противоречивыми.
Примитивный пример такой логики: при заполнении ВШГ в товарной номенклатуре, напишем триггер, который будет вычислять объём товара, и количество штук этого товара в кубе, а вычисленные поля класть сюда же, в номенклатуру. Вопрос, зачем это тянуть наружу и вычислять там? А если клиенты написаны под несколько платформ, на каждой эти вычисления писать? А если кто-то полез руками напрямую в таблицу исправлять ВШГ?
Меня, как абонента, это интересовать не должно. Я попросил оператора, не отдавать мне данные в роуминге. И дальше, как мне кажется, возможны два пути:
1. Оператор не отдаёт данные, потому что я в роуминге
2. Оператор отдаёт данные, потому что я в домашней сети
Если мне одной рукой отдают данные, а другой считают, что я за пределами дома, это какое-то лукавство.
Ехал я как-то из Москвы в Питер на Сапсане. С МегаФоном в качестве оператора. Умный такой, выключил роуминг данных, и, пока едем по московской области, на карту смотрю. Закончилось московская область, а интернет работает, вот и тверская закончилась, а он всё работает. Приехали в Питер, а карты по-прежнему пробки рисуют и вообще всё хорошо со скоростью.
А на следующий день у меня 800р. списали за роуминг данных. Да, за выключенный роуминг данных. То есть вышка абонентскому устройству говорит «ты в домашней сети», а сама всё правильно считает, как надо. И в колл-центре говорят – так и должно быть.
Ухудшения в производительности не заметил, примерно так же или быстрее (видимо за счёт более быстрого ssd). При том, что у меня всегда запущена виртуалка и ещё десяток приложений. Работаю за монитором с блютусной клавиатурой, ноут лежит рядом с закрытой крышкой.
Из плюсов: вес, время работы, производительность, возможность подключить к монитору один (!) кабель для видео, зарядки и аудио (чем я активно пользуюсь).
Из минусов: один разъём usb-c. Вынужден был поменять мышь (игровую логитек на логитек же, мх мастер 2эс).
А вот что сильно раздражает: когда думал про замену ноутбука, смотрел на мониторы с разъёмом usb-c. Разъём первый раз появился (в ноутбуках на рынке) около двух лет назад. А мониторов с диагональю 27" и более, на маркете, до сих пор, ровно 8 штук. Восемь! И кто стоит поперёк прогрессивных решений? При том, что это очень удобный вариант подключения, особенно, если в мониторе полноценный USB хаб.
Вот тоже за эти слова глаз зацепился. Вы либо можете измерить уровень, либо не можете. Как можно мерить учитывая фактор ускорения таяния вечных льдов?!
Вы могли бы, например, перестать оценивать что и насколько я понимаю, и с чем и в каких объёмах сталкивался, а? Спасибо.
Вот прям бред? Это потому, что вы не уверены в данных (вдруг их кто-то изменил), и хотите посчитать их динамически. А триггер, как раз эту уверенность даёт. Выражаясь в вашем стиле: это бред, считать динамически каждый раз, заведомо знаю, что ничего в таблице не поменялось.
Я, извините, категрически не верю, что фреймворк сгенерирует код триггера на изменение таблицы. Думаю там всё гораздо проще.
От того, что вы не видите SQL, не значит, что его нет, в итоге у вас и код фреймворка, и SQL, в котором вы разбираться не хотите, надеясь, что за вас напишут хорошо, красиво и быстро.
Написать посложнее я пробовал, получилось.В одной из сейчас работающих баз данных, 1400 хранимых процедур, большая часть, достаточно простая (CRUD), часть отчёты, часть совсем сложная (финансы, например), но оно работает и самодостаточно, приложение можно написать новое, а логика останется, хоть из командной строки работайте. Плюс на сервере сотня (100) linked server (в основном PostgreSQL), с которыми происходит постоянный обмен данными в обоих направлениях, и всё это (включая сотню постгресов) поддерживается мной. Времени именно на поддержку уходит мало, 1-2%. Я новое разрабатываю, а это живёт само.
Выглядит примерно так:
Хотя ниже по ветке я _наконец-то_ увидел аргументы, в пользу не разрешать прямое подключение к серверу БД, если речь про веб. Видимо, в таком случае, бэкэнд должен вызывать хранимые процедуры перекладывая параметры один-в-один.
И вместо того, чтобы дёргать из десктопа за ручки API, написанного на PHP, в котором всё равно написаны SQL команды, я буду дёргать за те же ручки, написанные сразу на SQL.
Для добавления книги позовём процедуру добавления, что-то типа
А всё, что происходит помимо собственно добавления книги, например поле «книг всего» у автора, напишу в триггере для таблицы Books
p. s. Клуб анонимных любителей залезть в данные напрямую :-)
Представьте, что такой частью является комплекс хранимых процедур, функций, триггеров. И скажите пожалуйста, что это за прокладка, с которой могут работать клиенты под разные платформы.
Это отвратительная практика. Но мне очень спокойно, что при любом исходе я не буду разгребать отрывочные сведения по всем таблицам. Почему-то первичный ключ использовать можно, а триггер, который поддерживает мою логику нельзя.
Откровенно неудобно писать одну и ту же логику на разных языках, с возможностью сделать ошибку в столько раз более вероятно, сколько языков используется.
Примитивный пример такой логики: при заполнении ВШГ в товарной номенклатуре, напишем триггер, который будет вычислять объём товара, и количество штук этого товара в кубе, а вычисленные поля класть сюда же, в номенклатуру. Вопрос, зачем это тянуть наружу и вычислять там? А если клиенты написаны под несколько платформ, на каждой эти вычисления писать? А если кто-то полез руками напрямую в таблицу исправлять ВШГ?
1. Оператор не отдаёт данные, потому что я в роуминге
2. Оператор отдаёт данные, потому что я в домашней сети
Если мне одной рукой отдают данные, а другой считают, что я за пределами дома, это какое-то лукавство.
А на следующий день у меня 800р. списали за роуминг данных. Да, за выключенный роуминг данных. То есть вышка абонентскому устройству говорит «ты в домашней сети», а сама всё правильно считает, как надо. И в колл-центре говорят – так и должно быть.
Если криптобиржи не регулируются, почему в отношении mt. gox ведётся расследование?