Не равносильно — двигатель с закрытым дросселем работает на ХХ, то есть поддерживает 800-1200 об/мин (современные ЭБУ часто специально увеличивают обороты ХХ при отпущенном дросселе на скорости для улучшения плавности переключения передач и уменьшения износа синхронизаторов), и гораздо легче докручивается колесами до соответствующих скорости оборотов (а они при езде внатяг не запредельные). ПХХ же включается при определенных условиях, и в современных программах в основном работает при сбросе газа с высоких оборотов, восстанавливая топливоподачу уже в районе 2000
Двигатель же вообще без топливоподачи мертв абсолютно. Хотя, конечно, и здесь есть нюансы — внезапная потеря топливоподачи в движении произойдет при приоткрытом дросселе (на то она и внезапная), что приведет к снижению требуемого момента прокрутки мотора, так что может и обойдется.
А вообще, здесь дело даже не в срыве или несрыве колес — это всего лишь еще один пример возможного сценария развития событий при отказе ЭБУ. Дело в том, что если существует вероятность потери управления автомобилем по вине самодельного ЭБУ (неважно каким способом и при каких внешних и внутренних условиях), и она выше той, что имеется у полностью стокового автомобиля — есть повод задуматься о pros and contras всей кухни. И заодно предостеречь тех, кто увидев дисклаймеры, не читая нажимает «I Agree».
Хаха — все зависит от рабочего объема мотора, включенной передачи и коэфф сцепления покрытия с колесами — на снегу или льду при езде внатяг, когда газом надо работать крайне аккуратно, резко заглохший двиг запросто спровоцирует блокировку и уход с дороги
Один вопрос — как вы собираетесь отлаживаться в случае «просто преобразования Фурье»? Да и hip9011 не так прост — у него переключаемый аттенюатор, банк фильтров и еще черта в ступе — и всем этим надо управлять в зависимости от частоты вращения КВ и настраивать под конкретный двигатель и место расположения датчика детонации. Соответственно, см предыдущий вопрос — как будете отлаживаться? Где возьмете область режимов работы двигателя, при которой детектируется детонация? Как будете оценивать результат? На слух?
Приведенный к общему виду Ваш вопрос звучит забавно — действительно ли так нужна RTOS, чтобы писать под ней риал-тайм приложения?
Ответ, в связке chibi и EFI, как ни странно, неоднозначен — под чиби писать легко и удобно, однако, например, нарушение соглашений вызовов функций ядра сваливает ее в полный стоп — что для EFI означает отсутствие управления мотором до следующего вотчдога.
Однако же, объезжать это управлением дисплеем через GPIO — решение по меньшей мере странное. Лучше уж пропатчить ядро, спросив у Джованни (автора чиби) как это сделать так, чтобы все не замерзало. А заодно и узнать, что он думает об automotive ее применении ;)
Просто начальная цель rusefi — afair любительские покатушки на закрытой трассе — это одно, а оснащение гражданских машин на дорогах общего пользования — совсем другое. Я думаю, что Джованни уже пора писать на chibios.org соответствующий дисклаймер…
Это же лежит на поверхности, вы ведь прикидываетесь, да?
Повисание контроллера на рискованном обгоне, или левом повороте -> отсутствие тяги на колесах -> ДТП -> кладбище.
Серия ранних углов ОЗ на высоких оборотах и нагрузках -> разрушительная детонация -> разрушение межкольцевых перемычек поршней -> ремонт ДВС (или так же, как в первом случае)
Это если нет электронного дросселя. Если он есть — то плюс все, что можно вообразить, если представить, что дроссель может быть нажат на 100% в любой произвольный момент времени — например, перед ПП, во дворе итд. Кроме того, нет никакой гарантии, например, что АЦП положения педали газа в контроллере коммерческого температурного диапазона в каком-нибудь из экземпляров ЭБУ не выдаст сигнал «полный дроссель» скажем при минус 30 за бортом и не нажатой педали — и дело будет даже не в софте…
Одометр — да. Похожую идею видел в самодельном станке для намотки трансформаторов — там тоже использовался калькулятор в качестве счетчика количества намотанных витков.
Если хотите поточнее выяснить длину окружности колеса — то нужно:
1. накачать колеса штатным давлением
2. сделать мелом вертикальную метку на покрышке
3. раскрутить по прямой рулетку, прижав чем-нибудь, чтобы не сворачивалась
4. сесть на вел (самому, вес важен!), сориентировав его вдоль рулетки меткой вниз, запомнить начальную цифру
5. прокатить строго вдоль рулетки точно на один оборот колеса (это делать лучше с помощником)
6. собственно, вычислить длину окружности по разнице двух меток :)
Реально, в теории автомобиля есть такой термин — динамический радиус колеса. Он, в частности, зависит нагрузки на колесо (а она, например, зависит от скорости из-за действия аэродинамических сил и центробежной силы вращающегося колеса, стремящегося увеличить его диаметр). Передаточные числа редуктора привода спидометра проектируют именно с учетом динамического радиуса.
Для велосипеда зависимостью от скорости можно пренебречь, но привести радиус (или путь одного оборота — ясное дело, неважно) к реальным условиям эксплуатации — тому давлению, до которого вы обычно качаете колеса, и весу самого седока — очень даже желательно. Если все сделаете правильно — получите погрешность не более нескольких метров на километр.
Это сейчас все просто — берется практически любой МК, минимум обвязки, блок индикации тоже готовый с уже встроенным контроллером — только код пиши. И то народ на ассемблере уже не хочет, и паяет с ленцой — все больше смотрят на готовые eval-борды да скетчи
А когда я в 88м году делал велоспидометр для своего Старт-Шоссе — иначе, как на россыпи было не сделать. У меня был спроектирован аппарат с тремя функциями — текущая скорость, максимальная скорость, пройденный путь, автоотключение ЖК при долгой остановке, сброс пути и максималки. Все вместе потянуло на пару десятков (!) корпусов 176 и 561 серии. Индикатор — 4-разрядный ЖК со статической индикацией (дефицит, между прочим был). Все размещалось на двух платах-слепышах одна над другой и индикатором сверху. Для компактности по высоте ИМС в дипах были распаяны псевдо-планарно — с отгибанием выводов в плоскость платы, монтаж — ПЭВТЛ (с залуживанием прямо во время пайки), питание — от четырех Д-0.1. Все вместе помещалось в нижнюю половину мыльницы :) размером примерно 100 * 70 * 25, с лицевой панелью из полированного оргстекла заподлицо. В стендбае конструкция потребляла всего порядка 3 микроампер, на ходу — порядка десятков, и могла жить целый сезон от одной зарядки.
Кстати, это сейчас программно можно подсчитать период и преобразовать его в скорость — а в устройстве на ИМС малой степени интеграции это было невозможно — попробуйте-ка выполнить деление на счетчиках и сдвиговых регистрах :). В итоге, приходилось считать частоту импульсов — а для того, чтобы время счета было приемлемым, на ступицу ставился не один магнит, а шесть (!). Но геркон, да был — действительно, самый экономичный вариант, как не требующий входных аналоговых активных компонентов — только пассивную схему антидребезга
Лечить table scan добавлением памяти и процессоров — это пять
— к сожалению, подобная практика мне встречалась и продолжает встречаться даже в очень серьезных системах — DBA пытаются изо всех сил исправить косяки проектирования, чем только могут — ставя 8-ядерные выделенные сервера с 64 Гб памяти только потому, что в тестовой конфигурации в ключевых таблицах было по 10^5 строк, а в продакшене — 10^7, а под лихой запрос разработчика, странслированный EF, не может быть использован ни один существующий или какой-нибудь новый индекс — в частности, и из-за корявости предикатов.
Аналогии по умолчанию лживы
— ваши измеряемые величины в разработке ПО — это метрики эффективности самого процесса разработки. А я говорю о метриках эффективности работы самой создаваемой системы, то есть результата этого процесса. И они больше зависят от качества проектирования, чем от качества ведения процесса разработки (если, конечно, интенсивность багов остается в разумных пределах).
При этом процесс проектирования программных систем необязательно должен опираться на математически строгую науку — в большинстве случаев хорошие и очень хорошие результаты получаются при примемении эвристик опытного проектировщика, хотя как раз бакенды очень хорошо покрываются теорией массового обслуживания. Так же, как для самолетов нужно избегать тяжелых материалов в размерных конструкциях, для бакендов нужно избегать статистически частых линейных операций над большими наборами данных. Для того, чтобы это сделать, не нужно знать ни физики, ни математики. Дальше желательно разносить потоки с существенно разным отношением R/W в разные объекты блокировки (в данном случае, таблицы). Минимизировать transaction footprint — то есть время-сечение объектов, которые затрагиваются транзакцией (на которые наложены локи) в течение бизнес-запроса.
Не выбирать ненужное (сюда varchar(max) out-of-row, included-колонки в индексах, и понимание преимуществ, которые дает плотность упаковки записей на страницу). Пакетность запросов — реализация преимуществ, которые дает масссовая обработка записей, и которая начисто отрезается при модификации данных средствами EF. Использование специфических возможностей DB engine — сюда идут OUTPUT-клаусы, встроенная атомарность, хинты, констрейнты, дефолтные функции, частичные индексы, синтезированные уникальные ключи, нереляционные джойны, генераторы данных итд.
Что-то в конце получилось сумбурно, но мысль такова, что DB engine обладает мощным набором *специфических для массовой обработки данных* фич, количество которых понемногу увеличивается от версии к версии (причем разработка этих фич совсем не бесплатна, а эффективность по крайней мере >= 0). Поскольку EF неспособен использовать значительную часть этих фич, а они продолжают существовать и развиваться — значит есть другой, более эффективный путь построения систем, без использования EF, для которого собственно множество этих фичей и продолжают поддерживать и наращивать.
Следующим шагом может быть внедрение поведенческого анализа в алгоритмы ботов и руткитов. Люди-шпионы ведь, получив вожделенный доступ, не стараются сразу все слить на родину, загружая эфир на 100% (если, конечно, не хотят, чтобы их тут же раскрыли), а ведут себя хладнокровно, как Штирлиц. И в итоге, побеждают в долгосрочной перспективе ). Также и боты — можно, получив доступ к ресурсам жертвы, некоторое время пособирать статистику, а потом уже потихоньку мимикрировать. Редких действий, подобных человеческим, точно никто не заметит, так как они не выйдут за пределы статшума
Я имел в виду то, что независимо от способа хранения, если вы затребуете SELECT * FROM XYZ, где * содержит CLOB или BLOB, то SQL server вытащит этот самый блоб и будет пропихивать его вам в резалтсете — и это и дает чудовищный оверхед по I/O Cost и network traffic, не говоря уже о затратах слоя приложения.
Помимо этого, In-row хуже с точки зрения плотности упаковки записей на страницу — а это очень важный параметр, в конечном итоге определяющий скорость выборки данных при любых способах (scan, seek, lookup, range), определяемых планом. Out-of-row можно enforce для строк любой длины, чтобы всегда можно было рассчитывать на плотную упаковку записей — msdn.microsoft.com/en-us/library/ms173530.aspx
Вообще пытаться оптимизировать структуру базы до того как оптимизированы запросы — контрпродуктивно
Ничего подобного! Просто разработчики обленились нормально проектировать до того, как положат пальцы на клавиатуру — так как все можно поменять быстро и на ходу, а заказчики, привыкнув к этому, теперь формулируют требования не до начала проектирования, а уже по факту первых версий продукта.
Структура базы определяется сущностями автоматизируемого процесса и операциями над ними. Далее идет итерация оптимизации по объему и скорости работы — еще до фактического написания слоя приложения — просто через анализ требований к работе с данными. Вопреки утверждениям «практиков», в большинстве случаев можно еще до фактического программирования сказать, в каком месте нужно во имя скорости отойти от НФ, где использовать массовые операции, где — специфические индексы, вычислимые поля, констрейнты итд.
При этом качество запросов к БД (которые еще не написаны), естественно, априори нужно подразумевать хорошим.
Тогда во время нагрузочного тестирования модификации не будут драматическими, а будут касаться лишь тех вещей, которые по ошибке были продуманы не так глубоко, или просто забыты.
Если же надеяться на то, что «минорные» проблемы на стейджинге (table scan в основных операциях, дедлоки, конфликты одновременной модификации итд) можно будет подлечить, набив памяти и добавив ядер в продакшен-сервер, или добавив каких-нибудь «магических» индексов (которые даже изобретать не надо — MS SQL студия теперь ведь умнее разработчиков — сама подсказывает, что сделать надо) — то вместо легкого и прозрачного бакенда вы получите утюг, который разгоняется только полной перепиской с нуля.
Аналогия тут с авиастроением — никому ведь не приходит в голову проектировать силовую схему планера из стали, и только убедившись в «неоптимальности конструкции», пытаться сначала высверлить отверстия в силовых конструкциях для облегчения, и лишь затем, пересобрав весь «солюшен», заменить материал на конструкционный алюминий.
То, что здесь процитировано, говорит лишь о том, что страница с данными не хранит сам CLOB — вместо него хранится указатель на CLOB в куче. Это увеличивает количество записей на страницу и помогает быстрее сканировать страницы при операциях, не затрагивающих сами клобы — то есть является по сути внутрисерверной реализацией идеи хранить клобы в отдельной таблице. Однако, от бесполезного вычитывания, передачи по сети в слой приложения и инициализации неиспользуемых полей, о котором говорится у топикстартера, это не спасает.
Второй абзац прекрасен, хоть и заставляет подозревать повышенную секрецию желчи ;)
Плюсую, так как человек особенно в детском возрасте имеет полное право быть огражденным от пошлости и банальности во всех пространствах — зрительном, звуковом, вкусовом, обонятельном и даже осязательном, ибо иначе велик шанс, что подросши, сам станет распространителем этой заразы дальше. В итоге общества, затрачивающие усилия на поддержание этого барьера, в долгосрочной перспективе выигрывают. Поэтому совсем не пронзительный звонок и грифельная доска хоронят национальный IQ, а нечто совсем другое.
А если серьезно — байесовские сети доверия вы, часом, не используете? По идее, они должны хорошо моделировать ситуации с последовательностями событий разной степени подозрительности
Подобным алгоритмом можно отслеживать девиантов в реальном мире — попил пива из горла на улице — +10, потыкал в домофон — еще +10, пробрался внутрь и пописал — +50. Типичные паттерны поведения всякой шушары можно вычленить из логов видеонаблюдения. Если порог превышен — сопоставлять с треками подключения мобильников к сотам, делать и запоминать ассоциацию — паттерн-номер телефона. Затем статистикой в конце месяца брать лидеров по очкам, автоматически генерировать ориентировки, ловить на типичных маршрутах и деактивировать штрафовать за нарушение общественного порядка — можно даже роботами-полицейскими.
для повышения точности хорошо бы, чтобы шестеренчатая передача была безлюфтовая — для этого ведомая шестерня делается составной из двух плоских шестеренок, имеющих определенную угловую подвижность друг относительно друга, и пружины между ними, стремящейся развести их зубья. В итоге, зацепление с ведущей шестерней становится безлюфтовым в пределах момента, компенсируемого силой пружины — так как зубья одной их шестерен всегда прижаты к переднему краю ведущих зубьев, а другой — к заднему. Такую конструкцию передачи можно взять из переменного конденсатора от старых ламповых приемников — типа такого
Насчет люфта гайка-резьбовая шпилька — он здесь тоже критичен, но зазор под весом фотоаппарата всегдя будет выбираться в одном направлении. Однако, для стабильной работы на высоких углах я бы дополнительно подгрузил его пружиной, стремящейся захлопнуть подвес
В диаметре все CR20xx емнип одинаковы и равны 20мм. Я имел в виду бутерброд — элемент, плата, пьезопищалка. Кнопку где-нить сбоку — конструктив типа электронных часов — кстати, корпус можно взять от них же. Насчет периода вейкапа — зная отношение цикла поллинга к минимальной длительности импульса от акселерометра, а также ток в powerdown и в active, можно прикинуть длительность автономной работы
Стремно это. Хоть устройство это и DIY и сертификации жизненно-важных устройств не подлежит (ЕМНИП у всех производителей МА в даташитах есть дисклаймер, что для подобного использования нужно их запрашивать явно), но от безотказности его работы действительно зависит жизнь человека, а беспроводной канал может банально сглючить из-за помех, скажем, от плохо экранированной микроволновки через стенку в соседней квартире. Тогда уж делать эту функцию дополнительной к оповещению самим устройством. И потом — поддержка стандартных беспроводных интерфейсов — энерго и вычислительноемка, а кастомные — не будут поддерживаться стандартными гаджетами из коробки, и в итоге вместо одного устройства нужно будет разрабатывать два
Корпусов и обвязки больше будет, чем при одном только контроллере. Мега, да — явно излишество, хватило бы и тини. Инвертирующий транзистор — тоже в топку — вместо аппаратного вейкапа лучше просыпаться раз в полсекунды по вотчдогу и поллить выход акселерометра. Пьезодинамик взять самый малеьнкий, раскачивать его для громкости можно с учетверенной мощностью, подключив обоими выходами к выводам порта и программно соорудив мостовую схему, подавая противоположные значения на выводы порта — как-то так. Деталей станет меньше, плату можно будет сделать размером с CR2032
Двигатель же вообще без топливоподачи мертв абсолютно. Хотя, конечно, и здесь есть нюансы — внезапная потеря топливоподачи в движении произойдет при приоткрытом дросселе (на то она и внезапная), что приведет к снижению требуемого момента прокрутки мотора, так что может и обойдется.
А вообще, здесь дело даже не в срыве или несрыве колес — это всего лишь еще один пример возможного сценария развития событий при отказе ЭБУ. Дело в том, что если существует вероятность потери управления автомобилем по вине самодельного ЭБУ (неважно каким способом и при каких внешних и внутренних условиях), и она выше той, что имеется у полностью стокового автомобиля — есть повод задуматься о pros and contras всей кухни. И заодно предостеречь тех, кто увидев дисклаймеры, не читая нажимает «I Agree».
Ответ, в связке chibi и EFI, как ни странно, неоднозначен — под чиби писать легко и удобно, однако, например, нарушение соглашений вызовов функций ядра сваливает ее в полный стоп — что для EFI означает отсутствие управления мотором до следующего вотчдога.
Однако же, объезжать это управлением дисплеем через GPIO — решение по меньшей мере странное. Лучше уж пропатчить ядро, спросив у Джованни (автора чиби) как это сделать так, чтобы все не замерзало. А заодно и узнать, что он думает об automotive ее применении ;)
Просто начальная цель rusefi — afair любительские покатушки на закрытой трассе — это одно, а оснащение гражданских машин на дорогах общего пользования — совсем другое. Я думаю, что Джованни уже пора писать на chibios.org соответствующий дисклаймер…
Повисание контроллера на рискованном обгоне, или левом повороте -> отсутствие тяги на колесах -> ДТП -> кладбище.
Серия ранних углов ОЗ на высоких оборотах и нагрузках -> разрушительная детонация -> разрушение межкольцевых перемычек поршней -> ремонт ДВС (или так же, как в первом случае)
Это если нет электронного дросселя. Если он есть — то плюс все, что можно вообразить, если представить, что дроссель может быть нажат на 100% в любой произвольный момент времени — например, перед ПП, во дворе итд. Кроме того, нет никакой гарантии, например, что АЦП положения педали газа в контроллере коммерческого температурного диапазона в каком-нибудь из экземпляров ЭБУ не выдаст сигнал «полный дроссель» скажем при минус 30 за бортом и не нажатой педали — и дело будет даже не в софте…
1. накачать колеса штатным давлением
2. сделать мелом вертикальную метку на покрышке
3. раскрутить по прямой рулетку, прижав чем-нибудь, чтобы не сворачивалась
4. сесть на вел (самому, вес важен!), сориентировав его вдоль рулетки меткой вниз, запомнить начальную цифру
5. прокатить строго вдоль рулетки точно на один оборот колеса (это делать лучше с помощником)
6. собственно, вычислить длину окружности по разнице двух меток :)
Реально, в теории автомобиля есть такой термин — динамический радиус колеса. Он, в частности, зависит нагрузки на колесо (а она, например, зависит от скорости из-за действия аэродинамических сил и центробежной силы вращающегося колеса, стремящегося увеличить его диаметр). Передаточные числа редуктора привода спидометра проектируют именно с учетом динамического радиуса.
Для велосипеда зависимостью от скорости можно пренебречь, но привести радиус (или путь одного оборота — ясное дело, неважно) к реальным условиям эксплуатации — тому давлению, до которого вы обычно качаете колеса, и весу самого седока — очень даже желательно. Если все сделаете правильно — получите погрешность не более нескольких метров на километр.
А когда я в 88м году делал велоспидометр для своего Старт-Шоссе — иначе, как на россыпи было не сделать. У меня был спроектирован аппарат с тремя функциями — текущая скорость, максимальная скорость, пройденный путь, автоотключение ЖК при долгой остановке, сброс пути и максималки. Все вместе потянуло на пару десятков (!) корпусов 176 и 561 серии. Индикатор — 4-разрядный ЖК со статической индикацией (дефицит, между прочим был). Все размещалось на двух платах-слепышах одна над другой и индикатором сверху. Для компактности по высоте ИМС в дипах были распаяны псевдо-планарно — с отгибанием выводов в плоскость платы, монтаж — ПЭВТЛ (с залуживанием прямо во время пайки), питание — от четырех Д-0.1. Все вместе помещалось в нижнюю половину мыльницы :) размером примерно 100 * 70 * 25, с лицевой панелью из полированного оргстекла заподлицо. В стендбае конструкция потребляла всего порядка 3 микроампер, на ходу — порядка десятков, и могла жить целый сезон от одной зарядки.
Кстати, это сейчас программно можно подсчитать период и преобразовать его в скорость — а в устройстве на ИМС малой степени интеграции это было невозможно — попробуйте-ка выполнить деление на счетчиках и сдвиговых регистрах :). В итоге, приходилось считать частоту импульсов — а для того, чтобы время счета было приемлемым, на ступицу ставился не один магнит, а шесть (!). Но геркон, да был — действительно, самый экономичный вариант, как не требующий входных аналоговых активных компонентов — только пассивную схему антидребезга
— ваши измеряемые величины в разработке ПО — это метрики эффективности самого процесса разработки. А я говорю о метриках эффективности работы самой создаваемой системы, то есть результата этого процесса. И они больше зависят от качества проектирования, чем от качества ведения процесса разработки (если, конечно, интенсивность багов остается в разумных пределах).
При этом процесс проектирования программных систем необязательно должен опираться на математически строгую науку — в большинстве случаев хорошие и очень хорошие результаты получаются при примемении эвристик опытного проектировщика, хотя как раз бакенды очень хорошо покрываются теорией массового обслуживания. Так же, как для самолетов нужно избегать тяжелых материалов в размерных конструкциях, для бакендов нужно избегать статистически частых линейных операций над большими наборами данных. Для того, чтобы это сделать, не нужно знать ни физики, ни математики. Дальше желательно разносить потоки с существенно разным отношением R/W в разные объекты блокировки (в данном случае, таблицы). Минимизировать transaction footprint — то есть время-сечение объектов, которые затрагиваются транзакцией (на которые наложены локи) в течение бизнес-запроса.
Не выбирать ненужное (сюда varchar(max) out-of-row, included-колонки в индексах, и понимание преимуществ, которые дает плотность упаковки записей на страницу). Пакетность запросов — реализация преимуществ, которые дает масссовая обработка записей, и которая начисто отрезается при модификации данных средствами EF. Использование специфических возможностей DB engine — сюда идут OUTPUT-клаусы, встроенная атомарность, хинты, констрейнты, дефолтные функции, частичные индексы, синтезированные уникальные ключи, нереляционные джойны, генераторы данных итд.
Что-то в конце получилось сумбурно, но мысль такова, что DB engine обладает мощным набором *специфических для массовой обработки данных* фич, количество которых понемногу увеличивается от версии к версии (причем разработка этих фич совсем не бесплатна, а эффективность по крайней мере >= 0). Поскольку EF неспособен использовать значительную часть этих фич, а они продолжают существовать и развиваться — значит есть другой, более эффективный путь построения систем, без использования EF, для которого собственно множество этих фичей и продолжают поддерживать и наращивать.
Помимо этого, In-row хуже с точки зрения плотности упаковки записей на страницу — а это очень важный параметр, в конечном итоге определяющий скорость выборки данных при любых способах (scan, seek, lookup, range), определяемых планом. Out-of-row можно enforce для строк любой длины, чтобы всегда можно было рассчитывать на плотную упаковку записей — msdn.microsoft.com/en-us/library/ms173530.aspx
Ничего подобного! Просто разработчики обленились нормально проектировать до того, как положат пальцы на клавиатуру — так как все можно поменять быстро и на ходу, а заказчики, привыкнув к этому, теперь формулируют требования не до начала проектирования, а уже по факту первых версий продукта.
Структура базы определяется сущностями автоматизируемого процесса и операциями над ними. Далее идет итерация оптимизации по объему и скорости работы — еще до фактического написания слоя приложения — просто через анализ требований к работе с данными. Вопреки утверждениям «практиков», в большинстве случаев можно еще до фактического программирования сказать, в каком месте нужно во имя скорости отойти от НФ, где использовать массовые операции, где — специфические индексы, вычислимые поля, констрейнты итд.
При этом качество запросов к БД (которые еще не написаны), естественно, априори нужно подразумевать хорошим.
Тогда во время нагрузочного тестирования модификации не будут драматическими, а будут касаться лишь тех вещей, которые по ошибке были продуманы не так глубоко, или просто забыты.
Если же надеяться на то, что «минорные» проблемы на стейджинге (table scan в основных операциях, дедлоки, конфликты одновременной модификации итд) можно будет подлечить, набив памяти и добавив ядер в продакшен-сервер, или добавив каких-нибудь «магических» индексов (которые даже изобретать не надо — MS SQL студия теперь ведь умнее разработчиков — сама подсказывает, что сделать надо) — то вместо легкого и прозрачного бакенда вы получите утюг, который разгоняется только полной перепиской с нуля.
Аналогия тут с авиастроением — никому ведь не приходит в голову проектировать силовую схему планера из стали, и только убедившись в «неоптимальности конструкции», пытаться сначала высверлить отверстия в силовых конструкциях для облегчения, и лишь затем, пересобрав весь «солюшен», заменить материал на конструкционный алюминий.
Плюсую, так как человек особенно в детском возрасте имеет полное право быть огражденным от пошлости и банальности во всех пространствах — зрительном, звуковом, вкусовом, обонятельном и даже осязательном, ибо иначе велик шанс, что подросши, сам станет распространителем этой заразы дальше. В итоге общества, затрачивающие усилия на поддержание этого барьера, в долгосрочной перспективе выигрывают. Поэтому совсем не пронзительный звонок и грифельная доска хоронят национальный IQ, а нечто совсем другое.
деактивироватьштрафовать за нарушение общественного порядка — можно даже роботами-полицейскими.Насчет люфта гайка-резьбовая шпилька — он здесь тоже критичен, но зазор под весом фотоаппарата всегдя будет выбираться в одном направлении. Однако, для стабильной работы на высоких углах я бы дополнительно подгрузил его пружиной, стремящейся захлопнуть подвес