Ну тогда наверное и на MSSQL Server тоже? И наверное на этих конкурентов все ориентируются, кто хочет занять свою нишу в сегменте реляционных СУБД. Просто не все позиционируют себя на этот уровень, отбрасывая сложные и дорогие фичи, чтобы удешевить продукт. Но рекомендации в общей части применимы ко всем РСУБД, которые оперируют сотнями и более гигабайт информации.
, то нужно секционировать данные и использовать локальные индексы, чтобы перестраивать индекс по ограниченному списку секций.
Это тоже нужно учитывать при проектировании.
Ограничения и так всегда отключены на работающих БД
ну знаете, это на ваших БД может и так, но для начинающего разработчика это не очевидно, и часто люди после проектирования OLTP с теми же подходами садятся за DWH.
Пометьте пожалуйста что это для Postgres
Как разраб Oracle могу утверждать, что не только для Postgres, а для продвинутых реляционных БД. Есть конечно «фичи» типа BRIN, но это частности.
А вот пометку что примеры приведены в синтаксисе Postgres можно.
Нужно начинать с того какие данные мы льем.
Если это OLTP там самое дешевое создать ограничения на уровне БД, и, почти всегда, этого достаточно. Хотя часто на обработку ошибок пользователей здесь работает клиентское приложение — меньше грузим сервер при массовом вводе данных.
Если это ETL из «чужого» нам источника, то использование ограничений это скорее всего малоэффективно, т.к. во первых тормозит, а во вторых работает только на отказ, и не рассматривает варианты — здесь лучше будет работать приложение работающее через промежуточную таблицу и способное скорректировать некоторые данные, хотя конечно бывает что нам достаточно получить отказ и сказать поставщику — исправляйте.
А при отлаженном ETL из знакомых нам источников данных в DWH, зачастую вообще нет никаких ограничений, т.к. они реально тормозят потоки, а вероятность случайной ошибки крайне низка. Индексы при этом действительно отключают и по завершению потока включают. т.к. это гораздо более эффективно. А если вы все таки получили ошибку по факту заливки — значит поток что-то не учитывает, но это редкая ситуация, или на источнике провели изменения о которых вы не знаете, всякое бывает, и для отлова таких ошибок создают DQC.
это норм, а то я уже начал сомневаться из-за фразы «от каждого потребителя».
но и на группы смысла особо не было, в одной комнате нагрузка 5.5кВт трудно представима.
По мне так на 41м ооочень много меди. 1.5 км…
Понятно что все из за централизации силового блока, но все равно, борщ.
Кроме того большая часть свистелок, как тут уже выражали мнение, это больше баловство чем реальная польза. Хотя конечно, все зависит от конкретного пользователя.
Проект конечно грандиозный, спору нет. Опыт. Сам с централизацией умного дома не заморачивался никогда. Но тут многие вещи в стиле «автоматизация ради автоматизации» — баланс IMHO слегка нарушен.
На лампочки, роутеры и прочие шторы 3х1.5 это многовато — там и пол-квадрата с головой, а можно и меньше с учетом «светодиодности».
Большое количество конденсаторов — замедляете переходной процесс в контуре, при нарастании тока «гвоздь» занимает положение в катушке соответствующее наименьшему магнитному сопротивлению, при этом в «гвозде» наводятся круговые токи. При смене направления тока в катушке, из-за колебательного характера переходного процесса, возникает выталкивающая сила стремящаяся поддержать направление магнитного потока в гвозде. В зависимости от дисбаланса в положении гвоздя, он будет вытолкнут по одному из двух направлений.
Токи при разряде больших батарей конденсаторов довольно большие, и энергии, выделяемой на контактном сопротивлении (хоть оно и небольшое) становится достаточно для локального расплавления контакта. Реле нужно было брать мощнее.
Если бы переходной процесс был рассчитан так, что гвоздь проходил точку с наименьшим магнитным сопротивлением в момент начала смены направления тока в катушке, то энергия гвоздя на вылете была бы еще больше и направление вылета было бы предсказуемо.
P.S. Насколько понял конденсаторы были не полярные.
Статья супер, несмотря на то что имелось общее представление, о некоторых тонкостях, до этой статьи, не было понимания.
Понятно что все намного сложнее, но для популяризации очень даже хорошо — и в школу бы зашло на ура.
Как тут уже писали, нужна начальная скорость снаряду, чтобы КПД был выше.
Для этого вполне можно использовать эжектор от пневмата.
Только тут сразу возникает проблема синхронизации подачи импульса на катушку, при прохождении снарядом определенной точки ствола.
Без фотодатчика тут не обойтись, и без долгой настройки задержки, при том что стабильной входной скорости от начальных разгонных модулей не получить никогда, т.к. есть множество факторов на нее влияющих.
И если такая свистопляска пошла, то почему тогда не добавить к устройству мозги и не обучить простенькую нейросеть на управление катушкой, а еще лучше несколькими каскадами катушек.
Понятно, проект для энтузиастов не самый простой, и сам, признаюсь, не взялся бы за него по причине отсутствия времени. Но я знавал увлеченных людей, которые делали и не такие чудеса.
Можно выполнить снаряд по принципу ротора асинхронного двигателя — на стальном сердечнике выполняются проточки которые заливаются алюминием по принципу короткозамкнутого витка. При разовом производстве такой снаряд конечно сильно сложнее, но при массовом это довольно дешево. Вопрос конечно еще с расчетами — насколько сильно можно закрутить такой снаряд импульсом с катушки.
:) в том то и дело, что в статье очень мало конкретики, и ваш описываемый опыт кажется просто внутренними проектами.
Вы мне попытались ответить на мой РИТОРИЧЕСКИЙ вопрос, но опять же исходя из абстрактной точки его приложения. А он касался именно ваших проектов из статьи, о которых ничего не рассказали.
Тема в общем не безынтересная.
Но не смотря на хорошее языковое качество и понятность общего смысла, в статье маловато конкретики. Проблемы описаны довольно абстрактно. Ошибки, победы, тонкие моменты, личные переживания. Обществу необходимо что-то анализировать и обсуждать, делать выводы и пользоваться опытом.
Чему учит нас эта статья? Что все не так просто? Да об этом и так все, мало-мальски соображающие, люди представление имеют.
Я понимаю, что додумывать за кого-то дело не благодарное, но все таки постараюсь сделать некоторые выводы, достроив статью тем, чего в ней не увидел.
Насколько я понял все идеи для воплощения были неразрывно связаны с деятельностью самого банка, а именно с кредитным направлением. Вопрос — с чего вы взяли что это может иметь отношение к предпринимательству? Чем реализация этих идей отличается от реализации обычного проекта в рамках организации?
Тут важно понимать — сможет ли проект жить обособлено от организации? Если нет — то это не стартап, это выделение части основного бизнеса в отдельный проект или структуру, которая без основного направления никакой ценности не имеет.
Даже создание отдельного юрлица, это фикция, если организация не может предоставить свои услуги другим участникам рынка, кроме материнской компании, за ненадобностью или по каким либо другим причинам. Вы просто сразу дали рынок сбыта услуги, как основной ее приобретатель, дали денег на реализацию и естественно вам самим и пришлось дотягивать идею, как свой собственный проект.
Другое дело если-бы идеи возникали вне рамок основного направления деятельности спонсора. В этом случае в распоряжении организатора есть весь рынок сбыта, на который он сам должен выйти. Вот это предпринимательство.
Как мне кажется это основная ваша ошибка — собирать идеи-сателлиты основному направлению, и выдавать это за предпринимательство.
Возможно я не все правильно понимаю, или не верно рассуждаю, ибо не эксперт в этом вопросе, но пока вижу все именно так.
Заявка на создание своего введения в реляционные БД для новичков имеет право на жизнь. Как говорится пока кому-нибудь не объяснишь, сам не поймешь. Написано конечно топорно, но не у каждого найдется сил и на это. Дальше только полировать.
Связи один-к-одному не такие уж и редкие. На больших объемах данных возникает необходимость в вертикальном секционировании для ускорения работы запросов.
Если некий объект имеет множество атрибутов, часть из которых используется очень часто, а часть очень редко, целесообразно хранить их отдельно друг от друга, чтобы уменьшить расходы на чтение диска.
«вторичный ключ» перекликается с «альтернативный ключ» — по этому это название плохо применимо для «foreign key» = «внешний ключ».
немного изучил вопрос по ПЭТ КТ на накопление амилоида, в Россию не завозят «химию» для таких тестов.
Т.е. нам пока остается только общий анализ белка в ликворе, который мы сделаем только если действительно будут проблемы, и который скажет только о том что что-то не в порядке (не обязательно укажет на конкретное заболевание), ну и собственно вскрытие.
Печалька.
Интересно, но читал через строчку, иногда через параграф — порог вхождения в тему очень высок и складывается только некая общая размытая картина. Выводы про «одну бессонную ночь» сильно настораживают — сколько их было…
Хотелось бы увидеть в статье, какие на сегодня есть тесты, кроме вскрытия, для оценки уровня накопления белков предположительно ответственных за развитие НДЗ, не помешало бы помониторить.
Ну тогда наверное и на MSSQL Server тоже? И наверное на этих конкурентов все ориентируются, кто хочет занять свою нишу в сегменте реляционных СУБД. Просто не все позиционируют себя на этот уровень, отбрасывая сложные и дорогие фичи, чтобы удешевить продукт. Но рекомендации в общей части применимы ко всем РСУБД, которые оперируют сотнями и более гигабайт информации.
, то нужно секционировать данные и использовать локальные индексы, чтобы перестраивать индекс по ограниченному списку секций.
Это тоже нужно учитывать при проектировании.
ну знаете, это на ваших БД может и так, но для начинающего разработчика это не очевидно, и часто люди после проектирования OLTP с теми же подходами садятся за DWH.
Как разраб Oracle могу утверждать, что не только для Postgres, а для продвинутых реляционных БД. Есть конечно «фичи» типа BRIN, но это частности.
А вот пометку что примеры приведены в синтаксисе Postgres можно.
Если это OLTP там самое дешевое создать ограничения на уровне БД, и, почти всегда, этого достаточно. Хотя часто на обработку ошибок пользователей здесь работает клиентское приложение — меньше грузим сервер при массовом вводе данных.
Если это ETL из «чужого» нам источника, то использование ограничений это скорее всего малоэффективно, т.к. во первых тормозит, а во вторых работает только на отказ, и не рассматривает варианты — здесь лучше будет работать приложение работающее через промежуточную таблицу и способное скорректировать некоторые данные, хотя конечно бывает что нам достаточно получить отказ и сказать поставщику — исправляйте.
А при отлаженном ETL из знакомых нам источников данных в DWH, зачастую вообще нет никаких ограничений, т.к. они реально тормозят потоки, а вероятность случайной ошибки крайне низка. Индексы при этом действительно отключают и по завершению потока включают. т.к. это гораздо более эффективно. А если вы все таки получили ошибку по факту заливки — значит поток что-то не учитывает, но это редкая ситуация, или на источнике провели изменения о которых вы не знаете, всякое бывает, и для отлова таких ошибок создают DQC.
но и на группы смысла особо не было, в одной комнате нагрузка 5.5кВт трудно представима.
Понятно что все из за централизации силового блока, но все равно, борщ.
Кроме того большая часть свистелок, как тут уже выражали мнение, это больше баловство чем реальная польза. Хотя конечно, все зависит от конкретного пользователя.
Проект конечно грандиозный, спору нет. Опыт. Сам с централизацией умного дома не заморачивался никогда. Но тут многие вещи в стиле «автоматизация ради автоматизации» — баланс IMHO слегка нарушен.
На лампочки, роутеры и прочие шторы 3х1.5 это многовато — там и пол-квадрата с головой, а можно и меньше с учетом «светодиодности».
Токи при разряде больших батарей конденсаторов довольно большие, и энергии, выделяемой на контактном сопротивлении (хоть оно и небольшое) становится достаточно для локального расплавления контакта. Реле нужно было брать мощнее.
Если бы переходной процесс был рассчитан так, что гвоздь проходил точку с наименьшим магнитным сопротивлением в момент начала смены направления тока в катушке, то энергия гвоздя на вылете была бы еще больше и направление вылета было бы предсказуемо.
P.S. Насколько понял конденсаторы были не полярные.
Понятно что все намного сложнее, но для популяризации очень даже хорошо — и в школу бы зашло на ура.
Для этого вполне можно использовать эжектор от пневмата.
Только тут сразу возникает проблема синхронизации подачи импульса на катушку, при прохождении снарядом определенной точки ствола.
Без фотодатчика тут не обойтись, и без долгой настройки задержки, при том что стабильной входной скорости от начальных разгонных модулей не получить никогда, т.к. есть множество факторов на нее влияющих.
И если такая свистопляска пошла, то почему тогда не добавить к устройству мозги и не обучить простенькую нейросеть на управление катушкой, а еще лучше несколькими каскадами катушек.
Понятно, проект для энтузиастов не самый простой, и сам, признаюсь, не взялся бы за него по причине отсутствия времени. Но я знавал увлеченных людей, которые делали и не такие чудеса.
Вы мне попытались ответить на мой РИТОРИЧЕСКИЙ вопрос, но опять же исходя из абстрактной точки его приложения. А он касался именно ваших проектов из статьи, о которых ничего не рассказали.
Но не смотря на хорошее языковое качество и понятность общего смысла, в статье маловато конкретики. Проблемы описаны довольно абстрактно. Ошибки, победы, тонкие моменты, личные переживания. Обществу необходимо что-то анализировать и обсуждать, делать выводы и пользоваться опытом.
Чему учит нас эта статья? Что все не так просто? Да об этом и так все, мало-мальски соображающие, люди представление имеют.
Я понимаю, что додумывать за кого-то дело не благодарное, но все таки постараюсь сделать некоторые выводы, достроив статью тем, чего в ней не увидел.
Насколько я понял все идеи для воплощения были неразрывно связаны с деятельностью самого банка, а именно с кредитным направлением. Вопрос — с чего вы взяли что это может иметь отношение к предпринимательству? Чем реализация этих идей отличается от реализации обычного проекта в рамках организации?
Тут важно понимать — сможет ли проект жить обособлено от организации? Если нет — то это не стартап, это выделение части основного бизнеса в отдельный проект или структуру, которая без основного направления никакой ценности не имеет.
Даже создание отдельного юрлица, это фикция, если организация не может предоставить свои услуги другим участникам рынка, кроме материнской компании, за ненадобностью или по каким либо другим причинам. Вы просто сразу дали рынок сбыта услуги, как основной ее приобретатель, дали денег на реализацию и естественно вам самим и пришлось дотягивать идею, как свой собственный проект.
Другое дело если-бы идеи возникали вне рамок основного направления деятельности спонсора. В этом случае в распоряжении организатора есть весь рынок сбыта, на который он сам должен выйти. Вот это предпринимательство.
Как мне кажется это основная ваша ошибка — собирать идеи-сателлиты основному направлению, и выдавать это за предпринимательство.
Возможно я не все правильно понимаю, или не верно рассуждаю, ибо не эксперт в этом вопросе, но пока вижу все именно так.
Связи один-к-одному не такие уж и редкие. На больших объемах данных возникает необходимость в вертикальном секционировании для ускорения работы запросов.
Если некий объект имеет множество атрибутов, часть из которых используется очень часто, а часть очень редко, целесообразно хранить их отдельно друг от друга, чтобы уменьшить расходы на чтение диска.
«вторичный ключ» перекликается с «альтернативный ключ» — по этому это название плохо применимо для «foreign key» = «внешний ключ».
Т.е. нам пока остается только общий анализ белка в ликворе, который мы сделаем только если действительно будут проблемы, и который скажет только о том что что-то не в порядке (не обязательно укажет на конкретное заболевание), ну и собственно вскрытие.
Печалька.
Хотелось бы увидеть в статье, какие на сегодня есть тесты, кроме вскрытия, для оценки уровня накопления белков предположительно ответственных за развитие НДЗ, не помешало бы помониторить.