Сообщение Re[27]: В России опять напишут новый объектно-ориентированны от 18.02.2018 7:30
Изменено 18.02.2018 7:39 vdimas
Re[27]: В России опять напишут новый объектно-ориентированны
Здравствуйте, IB, Вы писали:
>Ну теперь-то, надеюсь, вопросов будет поменьше, чего тебя тут большинство коллег игнорят, кроме rsdn team и "приближённых"?
IB>Ты опять находишь проблемы там где их нет. У меня нет проблем с тем, что меня кто-то игнорит, поэтому переставай пить коньяк по утрам
Я не сказал, что это «проблема», я просто констатирую факт – с тобой общаются не охотно. До тех пор, пока тебя это не беспокоит, это не является для тебя проблемой, разумеется.
V>>Специально за тобой не слежу, просто память хорошая,
IB>Ой, ну ладно, не оправдывайся, тут все свои )) Не стесняйся, я уже понял, что ты ко мне не равнодушен =)
Ровно в том же смысле не равнодушен, как и к нескольким сотням других коллег с этого сайта.
V>>Понятно, что у тебя с памятью похуже,
IB>Ты про меня уже целую биографию сочинил, хотя казалось бы, собрались пообсуждать недостатки SQL.
Не сочинил, мы с тобой уже общались несколько раз и все разы неудачно.
C тобой "пообсуждать" никак, бо происходящее всегда одинаково – не разобравшись влететь, понаставить диагнозов и гордо удалиться…
Никакие обсуждения тебя не интересуют, тебе подойдёт только «признание твоей правоты».
Как некий элемент традиции, вестимо.
Ну понятно, что "обсуждать" что-либо тут будет глупо, вот с тобой и не обсуждают.
Я ХЗ как некоторые не догоняют простых вещей, например, что сам по себе обмен аргументами в техническом споре – это нормально.
Но когда чел руинит спор, пресекая малейшие попытки обмена аргументами (причём, чаще не специально, а на твой манер — как слон в посудной лавке, что еще больше бесит, бо чел не видит себя со стороны), да еще если сам оказывается не прав технически (твои "невозможно знать заранее"), плюс еще ошибка детская – это всё составляет эпик фейл, аднака.
V>>Да, это всё учат в ВУЗ-ах профильных специальностей еще на 4-м курсе.
IB>В свое время, я этот курс читал в одном из не самых плохих вузов нашей прекрасной страны
«Этот курс»…
Этих курсов было как минимум 3 сильно разных.
Так перед кем ты опять пытаешься надуть своё ЧСВ?
Берем на те года специальности 2202 и 2204 — «автоматизированные системы обработки информации», «программное обеспечение выч. систем» или близкие к ним более поздние (с начальными индексами 6 и 7). Согласно твоих представлений о происходящем, скорее всего ты читал именно это. Бо именно в этих специальностях дают заметный упор на БД сугубо в прикладном плане. Они там, действительно, даже SQL учат, даже прямо на лекциях, а не на лабораторках и практических занятиях, ы-ы-ы.
Собсно, именно эти же специальности были и есть в том числе в виде среднего, а не высшего образования. Причём, как у нас, так и во всём мире — всякие колледжи и т.д., где тоже учат языкам программирования, в т.ч. SQL, а так же как правильно админить SQL-сервера, как запускать дефрагментацию индексов, зачем это надо и т.д. ))
Совсем другой курс читается на специальности 2201 «выч. машины, комплексы, сети» и близкой более поздней (после 94-го года) россыпи их. На этом курсе учат разрабатывать не прикладные БД, а именно СУБД. Учат не языку SQL, а навыкам разрабатывать языки, типа SQL, и весь механизм под ними.
Вот и получается у тебя смешная попытка манипулирования перед "остальными". Бо разве что вводный материал у этих курсов где-то похож, но целом м/у этими двумя направлениями чудовищная пропасть.
Чисто для сравнения (кому любопытно).
По первому направлению подготавливаются следующие специалисты (современное положение вещей):
• разработчик робототехнических систем и комплексов
• руководитель соответствующих подразделений
• разработчик систем управления и автоматики
• разработчик моделей обработки данных
• архитектор информационных систем
• специалист по проектированию и эксплуатации локальных вычислительных сетей
• специалист по эксплуатации информационных систем
• системный администратор
Вкратце — прикладуха и обслуживание ПО.
По второму:
• системный аналитик
• научный работник в области IT
• разработчик микропроцессорных систем
• проектировщик вычислительной техники
• специалист по наладке и ремонту выч. техники и их сетей
• системный программист
• инженер-системотехник
Вкратце — разработка программно-аппаратных выч. систем, "платформ", исследования в этом направлении.
На Западе это известное отличие читается как отличие "разработчика информационных систем" от "системного аналитика".
"Системный аналитик" – это наиболее близкий западный аналог нашей специальности «инженер-системотехник», где первое название в последние лет 10-15 всё охотнее применяется вместо второго.
Характерно (опять же, судя по обсуждениям тут) что эту специальность многие наши коллеги не понимают, часто путают с аналитиком предметной области – т.е. с «бизнес-аналитиком». А даже те, кто понимают эту специальность, часто невольно выхолащивают её до «сбора требований и постановки задачи», хотя это лишь малая часть деятельности. Просто одна из самых важных в IT (ИМХО), но всё-равно, это лишь некий этап разработки, а не она вся.
(да, тут на сайте регулярно замечаю даже за весьма неглыпыми коллегами откровенно неудовлетворительные навыки формулирования проблематики, поубывав бы).
Системный аналитик не просто ставит задачу, а хорошо ориентируется в техническом аспекте её реализуемости, т.е. проводит поиск решений в ограничениях. Работа циничная и творческая одновременно. Именно для этого его взращивали как междисциплинарного специалиста, т.е. такого, который владеет как прикладными аспектами, так и системными, вплоть до особенностей железа, линий связи и т.д. Вплоть до того, что недостающее железо, линии передачи информации (сам их физический принцип или вплоть до способа модуляции несущих и поднесущих) или недостающее низкоуровневое программное обеспечение – всё это запросто реализуется в рамках проекта и я такое делал не раз.
"Прикладникам" такие фокусы не доступны, но прикладники и не разрабатывают движки БД, а обсуждалось именно это.
Известный "мем" — это как если прикладник в Дельфи не нашёл нужный ТКомпонент, то задача не имеет решения. ))
Собсно, нигде в мире отдельных "низкоуровневых системщиков" не готовили и готовить никогда не будут. Любой "низкоуровневый системщик" во всём мире готовится исключительно как "системный аналитик" и никак иначе, потому что разработка "базы", "платформы" — это наиболее ответственная часть в современном IT, по понятной приине — ошибки на этом уровне чудовищно дорогие из-за эффекта масштабирования.
Например, пользователю БД важно написать правильный SQL запрос к СУБД, но гораздо важнее, чтобы ЛЮБОЙ допустимый запрос правильно отработал на стороне самой СУБД.
IB>так что давай, расскажи мне чему учат на профильных специальностях
А то ты не знал?
Девочку из себя строить было не обязательно.
Пришлось расписать суть твоего манипулирования.
Ну, чтобы, не слишком гордо удалялся, угу.
IB>Буквально как в анекдоте — "там где вы учились, мы преподавали"
Хы-хы.
"Вы" не могли преподавать там, где я учился, иначе бы "вы" не палились насчёт "посмотри, сколько много закешировано планов".
Пока что ты дал понять, что не в курсе, в каком виде эти планы хранятся, какие там структуры данных и как можно на них сэкономить на порядок-другой, если дать достаточно времени на тождественные преобразования замкнутой системы уравнений РИ.
Да и вообще, чужая недогадливость — она всегда раздражает. У тебя достаточно опыта чтобы знать — современные СУБД часто не в состоянии отличить два простых запроса, отличающихся одной вшивой константой в предикате ограничения. Именно поэтому "руководство пользователя" СУБД прямо рекомендует превращать такие однотипные запросы в запросы с параметром и делать им prepare, иначе система будет динамически плодить всё новые и новые планы запросов, к количеству которых ты апеллируешь. Добавь к этому тот факт, что СУБД запросто считает разными даже совершенно идентичные по-сути запросы, но с небольшой переформулировкой выражений в нём, т.е. плодит и плодит в том числе идентичные наборы планов, сцуко. Кароч, из-за всей абсурдности этого цирка я уже не знаю, смеяться мне или плакать и куда я вообще попал? ))
С одной стороны (мне казалось это очевидным для всех), при статической компиляции запросы с параметрами + prepare будут как мёртвому припарка, бо и без подсказок со стороны сопливых компилятор прекрасно разберётся. Причём, он разберётся и найдёт идентичности даже там, где ты и вообразить не мог, даже у тех запросов или частей их, которые никак не кажутся похожими.
С другой стороны, мне тут в лицо аргументы – идите почитайте про "prepare". ))
«Вот вам букварь» — мой ответ.
Но хрен с ним, идём далее.
Когда речь о компиляции алгоритма над константными структурами данных, то сами данные часто исчезают – превращаются тупо в код (раскрутка циклов и рекурсивных вызовов и всё это опять рекурсивно). Тем самым убирается еще один уровень интерпретирования над данными, который практически всегда есть даже в самой-пресамой нейтивной программе над неконстантными данными. Но мы-то говорим о константных данных, т.е. которые можно превращать в код (всё мн-во запросов и планов по ним).
Или еще пример – во многих "больших" системах в избытке наличествуют данные справочного характера, причём, некоторые из этих данных меняются очень редко или не меняются никогда (для примера – виды ордеров, т.е. такие данные, которые бесполезно менять без изменений в коде, т.е. для данного состояния кода они, по-сути, не меняются). Т.е., хватает таблиц небольшого размера, которые можно считать эдаким способом подробного описания enum-ов, просто на стороне базы, а не на клиенте. Всю эту шелуху тоже можно убрать нафик из таблиц (убрать сами таблицы), тупо инлайня код с их участием. Подобных мелочей хватает, но они могут кардинально влиять на происходящее, делая ассоциации "бесплатными" — например, вместо ID такого enum в других таблицах можно хранить физическое смещение на структуру в сегменте константных данных скомпиллированного бинарника. И такий мелочей, стоит только ногтём подцепить, — овердохрена.
Так же я давал оценку «распухания кода» (дополнительного объема) и сравнивал сие с объемом кода, который требуется для работы нынешней динамической системы (изымаемого объема). В динамической системе сегодня живёт и компилятор и интерпретатор, но это ж чудовищный объем функциональности, который и нафик не сдался скомпиллированному бинарнику.
И пусть мои прикидки грубые – это же лишь затравка для начала обсуждения, не? ))
Например, мне тут "напомнили", что в средней прикладной базе живёт пару тыс и более запросов. У меня и ответ давно имеется – там (грубо) 80% кода, считай, дублирует друг друга, а из оставшихся 20% половина является библиотечным слоем. Т.е. в случае компиляции дублирование исчезает и с библиотеками всяко получше, бо для статически собираемой системы объем данных свыше библиотек теоретически не ограничен – всё-равно в бинарь попадёт только используемое по-факту. Совсем другое дело для динамических систем, верно? Там особо не разбежишься с библиотеками.
V>> если предположить гипотеитческий вариант "все запросы известны заранее".
IB>Тот факт, что это гипотетическое предположение ошибочно, ты предпочел проигнорировать.
IB>Конечно, это же разрушит такую прекрасную теорию.
Если сам не понимаешь — спроси у коллег, хосподя, например, из вашей же rsdn team. Большинство из них (или даже все поголовно) прекрасно понимают, почему в случае статической компиляции "все запросы известны заранее" (С). И это вообще не теория, это постулат, условие существования такой системы.
V>>Мы были вынуждены писать учётные системы с бухгелтериями и прочий сугубо прикладной шлак уровня домохозяек с PHP, вместо того, чтобы участвовать в разработках самих технологий.
IB>В очередной раз советую тебе не судить обо всех по себе.
Я могу судить лишь по открытым источникам — по твоим статьям и по тому, что ты писал в форумы в те годы, когда был активен.
Кароч, это всё гребанный PHP, вид сбоку.
Я ХЗ как лично ты на это смотришь, но мне в те годы было стыдно каждую секунду такого времяпрепровождения.
С тем же успехом можно было бесконечно админить линуха какие-нить. Тем более, что до этого уже довелось поработать ~6 лет именно системщиком, а не прикладником. И если ты сейчас более не занимаешься такой юзверской деятельностью, а сам участвуешь в разработке технологий, то я только за тебя порадуюсь, мне не жалко. Но в этот спор ты влез, увы, с колокольни махрового юзера с раненным ЧСВ.
>Ну теперь-то, надеюсь, вопросов будет поменьше, чего тебя тут большинство коллег игнорят, кроме rsdn team и "приближённых"?
IB>Ты опять находишь проблемы там где их нет. У меня нет проблем с тем, что меня кто-то игнорит, поэтому переставай пить коньяк по утрам
Я не сказал, что это «проблема», я просто констатирую факт – с тобой общаются не охотно. До тех пор, пока тебя это не беспокоит, это не является для тебя проблемой, разумеется.
V>>Специально за тобой не слежу, просто память хорошая,
IB>Ой, ну ладно, не оправдывайся, тут все свои )) Не стесняйся, я уже понял, что ты ко мне не равнодушен =)
Ровно в том же смысле не равнодушен, как и к нескольким сотням других коллег с этого сайта.
V>>Понятно, что у тебя с памятью похуже,
IB>Ты про меня уже целую биографию сочинил, хотя казалось бы, собрались пообсуждать недостатки SQL.
Не сочинил, мы с тобой уже общались несколько раз и все разы неудачно.
C тобой "пообсуждать" никак, бо происходящее всегда одинаково – не разобравшись влететь, понаставить диагнозов и гордо удалиться…
Никакие обсуждения тебя не интересуют, тебе подойдёт только «признание твоей правоты».
Как некий элемент традиции, вестимо.
Ну понятно, что "обсуждать" что-либо тут будет глупо, вот с тобой и не обсуждают.
Я ХЗ как некоторые не догоняют простых вещей, например, что сам по себе обмен аргументами в техническом споре – это нормально.
Но когда чел руинит спор, пресекая малейшие попытки обмена аргументами (причём, чаще не специально, а на твой манер — как слон в посудной лавке, что еще больше бесит, бо чел не видит себя со стороны), да еще если сам оказывается не прав технически (твои "невозможно знать заранее"), плюс еще ошибка детская – это всё составляет эпик фейл, аднака.
V>>Да, это всё учат в ВУЗ-ах профильных специальностей еще на 4-м курсе.
IB>В свое время, я этот курс читал в одном из не самых плохих вузов нашей прекрасной страны
«Этот курс»…
Этих курсов было как минимум 3 сильно разных.
Так перед кем ты опять пытаешься надуть своё ЧСВ?
Берем на те года специальности 2202 и 2204 — «автоматизированные системы обработки информации», «программное обеспечение выч. систем» или близкие к ним более поздние (с начальными индексами 6 и 7). Согласно твоих представлений о происходящем, скорее всего ты читал именно это. Бо именно в этих специальностях дают заметный упор на БД сугубо в прикладном плане. Они там, действительно, даже SQL учат, даже прямо на лекциях, а не на лабораторках и практических занятиях, ы-ы-ы.
Собсно, именно эти же специальности были и есть в том числе в виде среднего, а не высшего образования. Причём, как у нас, так и во всём мире — всякие колледжи и т.д., где тоже учат языкам программирования, в т.ч. SQL, а так же как правильно админить SQL-сервера, как запускать дефрагментацию индексов, зачем это надо и т.д. ))
Совсем другой курс читается на специальности 2201 «выч. машины, комплексы, сети» и близкой более поздней (после 94-го года) россыпи их. На этом курсе учат разрабатывать не прикладные БД, а именно СУБД. Учат не языку SQL, а навыкам разрабатывать языки, типа SQL, и весь механизм под ними.
Вот и получается у тебя смешная попытка манипулирования перед "остальными". Бо разве что вводный материал у этих курсов где-то похож, но целом м/у этими двумя направлениями чудовищная пропасть.
Чисто для сравнения (кому любопытно).
По первому направлению подготавливаются следующие специалисты (современное положение вещей):
• разработчик робототехнических систем и комплексов
• руководитель соответствующих подразделений
• разработчик систем управления и автоматики
• разработчик моделей обработки данных
• архитектор информационных систем
• специалист по проектированию и эксплуатации локальных вычислительных сетей
• специалист по эксплуатации информационных систем
• системный администратор
Вкратце — прикладуха и обслуживание ПО.
По второму:
• системный аналитик
• научный работник в области IT
• разработчик микропроцессорных систем
• проектировщик вычислительной техники
• специалист по наладке и ремонту выч. техники и их сетей
• системный программист
• инженер-системотехник
Вкратце — разработка программно-аппаратных выч. систем, "платформ", исследования в этом направлении.
На Западе это известное отличие читается как отличие "разработчика информационных систем" от "системного аналитика".
"Системный аналитик" – это наиболее близкий западный аналог нашей специальности «инженер-системотехник», где первое название в последние лет 10-15 всё охотнее применяется вместо второго.
Характерно (опять же, судя по обсуждениям тут) что эту специальность многие наши коллеги не понимают, часто путают с аналитиком предметной области – т.е. с «бизнес-аналитиком». А даже те, кто понимают эту специальность, часто невольно выхолащивают её до «сбора требований и постановки задачи», хотя это лишь малая часть деятельности. Просто одна из самых важных в IT (ИМХО), но всё-равно, это лишь некий этап разработки, а не она вся.
(да, тут на сайте регулярно замечаю даже за весьма неглыпыми коллегами откровенно неудовлетворительные навыки формулирования проблематики, поубывав бы).
Системный аналитик не просто ставит задачу, а хорошо ориентируется в техническом аспекте её реализуемости, т.е. проводит поиск решений в ограничениях. Работа циничная и творческая одновременно. Именно для этого его взращивали как междисциплинарного специалиста, т.е. такого, который владеет как прикладными аспектами, так и системными, вплоть до особенностей железа, линий связи и т.д. Вплоть до того, что недостающее железо, линии передачи информации (сам их физический принцип или вплоть до способа модуляции несущих и поднесущих) или недостающее низкоуровневое программное обеспечение – всё это запросто реализуется в рамках проекта и я такое делал не раз.
"Прикладникам" такие фокусы не доступны, но прикладники и не разрабатывают движки БД, а обсуждалось именно это.
Известный "мем" — это как если прикладник в Дельфи не нашёл нужный ТКомпонент, то задача не имеет решения. ))
Собсно, нигде в мире отдельных "низкоуровневых системщиков" не готовили и готовить никогда не будут. Любой "низкоуровневый системщик" во всём мире готовится исключительно как "системный аналитик" и никак иначе, потому что разработка "базы", "платформы" — это наиболее ответственная часть в современном IT, по понятной приине — ошибки на этом уровне чудовищно дорогие из-за эффекта масштабирования.
Например, пользователю БД важно написать правильный SQL запрос к СУБД, но гораздо важнее, чтобы ЛЮБОЙ допустимый запрос правильно отработал на стороне самой СУБД.
IB>так что давай, расскажи мне чему учат на профильных специальностях
А то ты не знал?
Девочку из себя строить было не обязательно.
Пришлось расписать суть твоего манипулирования.
Ну, чтобы, не слишком гордо удалялся, угу.
IB>Буквально как в анекдоте — "там где вы учились, мы преподавали"
Хы-хы.
"Вы" не могли преподавать там, где я учился, иначе бы "вы" не палились насчёт "посмотри, сколько много закешировано планов".
Пока что ты дал понять, что не в курсе, в каком виде эти планы хранятся, какие там структуры данных и как можно на них сэкономить на порядок-другой, если дать достаточно времени на тождественные преобразования замкнутой системы уравнений РИ.
Да и вообще, чужая недогадливость — она всегда раздражает. У тебя достаточно опыта чтобы знать — современные СУБД часто не в состоянии отличить два простых запроса, отличающихся одной вшивой константой в предикате ограничения. Именно поэтому "руководство пользователя" СУБД прямо рекомендует превращать такие однотипные запросы в запросы с параметром и делать им prepare, иначе система будет динамически плодить всё новые и новые планы запросов, к количеству которых ты апеллируешь. Добавь к этому тот факт, что СУБД запросто считает разными даже совершенно идентичные по-сути запросы, но с небольшой переформулировкой выражений в нём, т.е. плодит и плодит в том числе идентичные наборы планов, сцуко. Кароч, из-за всей абсурдности этого цирка я уже не знаю, смеяться мне или плакать и куда я вообще попал? ))
С одной стороны (мне казалось это очевидным для всех), при статической компиляции запросы с параметрами + prepare будут как мёртвому припарка, бо и без подсказок со стороны сопливых компилятор прекрасно разберётся. Причём, он разберётся и найдёт идентичности даже там, где ты и вообразить не мог, даже у тех запросов или частей их, которые никак не кажутся похожими.
С другой стороны, мне тут в лицо аргументы – идите почитайте про "prepare". ))
«Вот вам букварь» — мой ответ.
Но хрен с ним, идём далее.
Когда речь о компиляции алгоритма над константными структурами данных, то сами данные часто исчезают – превращаются тупо в код (раскрутка циклов и рекурсивных вызовов и всё это опять рекурсивно). Тем самым убирается еще один уровень интерпретирования над данными, который практически всегда есть даже в самой-пресамой нейтивной программе над неконстантными данными. Но мы-то говорим о константных данных, т.е. которые можно превращать в код (всё мн-во запросов и планов по ним).
Или еще пример – во многих "больших" системах в избытке наличествуют данные справочного характера, причём, некоторые из этих данных меняются очень редко или не меняются никогда (для примера – виды ордеров, т.е. такие данные, которые бесполезно менять без изменений в коде, т.е. для данного состояния кода они, по-сути, не меняются). Т.е., хватает таблиц небольшого размера, которые можно считать эдаким способом подробного описания enum-ов, просто на стороне базы, а не на клиенте. Всю эту шелуху тоже можно убрать нафик из таблиц (убрать сами таблицы), тупо инлайня код с их участием. Подобных мелочей хватает, но они могут кардинально влиять на происходящее, делая ассоциации "бесплатными" — например, вместо ID такого enum в других таблицах можно хранить физическое смещение на структуру в сегменте константных данных скомпиллированного бинарника. И такий мелочей, стоит только ногтём подцепить, — овердохрена.
Так же я давал оценку «распухания кода» (дополнительного объема) и сравнивал сие с объемом кода, который требуется для работы нынешней динамической системы (изымаемого объема). В динамической системе сегодня живёт и компилятор и интерпретатор, но это ж чудовищный объем функциональности, который и нафик не сдался скомпиллированному бинарнику.
И пусть мои прикидки грубые – это же лишь затравка для начала обсуждения, не? ))
Например, мне тут "напомнили", что в средней прикладной базе живёт пару тыс и более запросов. У меня и ответ давно имеется – там (грубо) 80% кода, считай, дублирует друг друга, а из оставшихся 20% половина является библиотечным слоем. Т.е. в случае компиляции дублирование исчезает и с библиотеками всяко получше, бо для статически собираемой системы объем данных свыше библиотек теоретически не ограничен – всё-равно в бинарь попадёт только используемое по-факту. Совсем другое дело для динамических систем, верно? Там особо не разбежишься с библиотеками.
V>> если предположить гипотеитческий вариант "все запросы известны заранее".
IB>Тот факт, что это гипотетическое предположение ошибочно, ты предпочел проигнорировать.
IB>Конечно, это же разрушит такую прекрасную теорию.
Если сам не понимаешь — спроси у коллег, хосподя, например, из вашей же rsdn team. Большинство из них (или даже все поголовно) прекрасно понимают, почему в случае статической компиляции "все запросы известны заранее" (С). И это вообще не теория, это постулат, условие существования такой системы.
V>>Мы были вынуждены писать учётные системы с бухгелтериями и прочий сугубо прикладной шлак уровня домохозяек с PHP, вместо того, чтобы участвовать в разработках самих технологий.
IB>В очередной раз советую тебе не судить обо всех по себе.
Я могу судить лишь по открытым источникам — по твоим статьям и по тому, что ты писал в форумы в те годы, когда был активен.
Кароч, это всё гребанный PHP, вид сбоку.
Я ХЗ как лично ты на это смотришь, но мне в те годы было стыдно каждую секунду такого времяпрепровождения.
С тем же успехом можно было бесконечно админить линуха какие-нить. Тем более, что до этого уже довелось поработать ~6 лет именно системщиком, а не прикладником. И если ты сейчас более не занимаешься такой юзверской деятельностью, а сам участвуешь в разработке технологий, то я только за тебя порадуюсь, мне не жалко. Но в этот спор ты влез, увы, с колокольни махрового юзера с раненным ЧСВ.Re[27]: В России опять напишут новый объектно-ориентированны
Здравствуйте, IB, Вы писали:
>Ну теперь-то, надеюсь, вопросов будет поменьше, чего тебя тут большинство коллег игнорят, кроме rsdn team и "приближённых"?
IB>Ты опять находишь проблемы там где их нет. У меня нет проблем с тем, что меня кто-то игнорит, поэтому переставай пить коньяк по утрам
Я не сказал, что это «проблема», я просто констатирую факт – с тобой общаются не охотно. До тех пор, пока тебя это не беспокоит, это не является для тебя проблемой, разумеется.
V>>Специально за тобой не слежу, просто память хорошая,
IB>Ой, ну ладно, не оправдывайся, тут все свои )) Не стесняйся, я уже понял, что ты ко мне не равнодушен =)
Ровно в том же смысле не равнодушен, как и к нескольким сотням других коллег с этого сайта.
V>>Понятно, что у тебя с памятью похуже,
IB>Ты про меня уже целую биографию сочинил, хотя казалось бы, собрались пообсуждать недостатки SQL.
Не сочинил, мы с тобой уже общались несколько раз и все разы неудачно.
C тобой "пообсуждать" никак, бо происходящее всегда одинаково – не разобравшись влететь, понаставить диагнозов и гордо удалиться…
Никакие обсуждения тебя не интересуют, тебе подойдёт только «признание твоей правоты».
Как некий элемент традиции, вестимо.
Ну понятно, что "обсуждать" что-либо тут будет глупо, вот с тобой и не обсуждают.
Я ХЗ как некоторые не догоняют простых вещей, например, что сам по себе обмен аргументами в техническом споре – это нормально.
Но когда чел руинит спор, пресекая малейшие попытки обмена аргументами (причём, чаще не специально, а на твой манер — как слон в посудной лавке, что еще больше бесит, бо чел не видит себя со стороны), да еще если сам оказывается не прав технически (твои "невозможно знать заранее"), плюс еще ошибка детская – это всё составляет эпик фейл, аднака.
V>>Да, это всё учат в ВУЗ-ах профильных специальностей еще на 4-м курсе.
IB>В свое время, я этот курс читал в одном из не самых плохих вузов нашей прекрасной страны
«Этот курс»…
Этих курсов было как минимум 3 сильно разных.
Так перед кем ты опять пытаешься надуть своё ЧСВ?
Берем на те года специальности 2202 и 2204 — «автоматизированные системы обработки информации», «программное обеспечение выч. систем» или близкие к ним более поздние (с начальными индексами 6 и 7). Согласно твоих представлений о происходящем, скорее всего ты читал именно это. Бо именно в этих специальностях дают заметный упор на БД сугубо в прикладном плане. Они там, действительно, даже SQL учат, даже прямо на лекциях, а не на лабораторках и практических занятиях, ы-ы-ы.
Собсно, именно эти же специальности были и есть в том числе в виде среднего, а не высшего образования. Причём, как у нас, так и во всём мире — всякие колледжи и т.д., где тоже учат языкам программирования, в т.ч. SQL, а так же как правильно админить SQL-сервера, как запускать дефрагментацию индексов, зачем это надо и т.д. ))
Совсем другой курс читается на специальности 2201 «выч. машины, комплексы, сети» и близкой более поздней (после 94-го года) россыпи их. На этом курсе учат разрабатывать не прикладные БД, а именно СУБД. Учат не языку SQL, а навыкам разрабатывать языки, типа SQL, и весь механизм под ними.
Вот и получается у тебя смешная попытка манипулирования перед "остальными". Бо разве что вводный материал у этих курсов где-то похож, но целом м/у этими двумя направлениями чудовищная пропасть.
Чисто для сравнения (кому любопытно).
По первому направлению подготавливаются следующие специалисты (современное положение вещей):
• разработчик робототехнических систем и комплексов
• руководитель соответствующих подразделений
• разработчик систем управления и автоматики
• разработчик моделей обработки данных
• архитектор информационных систем
• специалист по проектированию и эксплуатации локальных вычислительных сетей
• специалист по эксплуатации информационных систем
• системный администратор
Вкратце — прикладуха и обслуживание ПО.
По второму:
• системный аналитик
• научный работник в области IT
• разработчик микропроцессорных систем
• проектировщик вычислительной техники
• специалист по наладке и ремонту выч. техники и их сетей
• системный программист
• инженер-системотехник
Вкратце — разработка программно-аппаратных выч. систем, "платформ", исследования в этом направлении.
На Западе это известное отличие читается как отличие "разработчика информационных систем" от "системного аналитика".
"Системный аналитик" – это наиболее близкий западный аналог нашей специальности «инженер-системотехник», где первое название в последние лет 10-15 всё охотнее применяется вместо второго.
Характерно (опять же, судя по обсуждениям тут) что эту специальность многие наши коллеги не понимают, часто путают с аналитиком предметной области – т.е. с «бизнес-аналитиком». А даже те, кто понимают эту специальность, часто невольно выхолащивают её до «сбора требований и постановки задачи», хотя это лишь малая часть деятельности. Просто одна из самых важных в IT (ИМХО), но всё-равно, это лишь некий этап разработки, а не она вся.
(да, тут на сайте регулярно замечаю даже за весьма неглупыми коллегами откровенно неудовлетворительные навыки формулирования проблематики, поубывав бы).
Системный аналитик не просто ставит задачу, а хорошо ориентируется в техническом аспекте её реализуемости, т.е. проводит поиск решений в ограничениях. Работа циничная и творческая одновременно. Именно для этого его взращивали как междисциплинарного специалиста, т.е. такого, который владеет как прикладными аспектами, так и системными, вплоть до особенностей железа, линий связи и т.д. Вплоть до того, что недостающее железо, линии передачи информации (сам их физический принцип или вплоть до способа модуляции несущих и поднесущих) или недостающее низкоуровневое программное обеспечение – всё это запросто реализуется в рамках проекта и я такое делал не раз.
"Прикладникам" такие фокусы не доступны, но прикладники и не разрабатывают движки БД, а обсуждалось именно это.
Известный "мем" — это как если прикладник в Дельфи не нашёл нужный ТКомпонент, то задача не имеет решения. ))
Собсно, нигде в мире отдельных "низкоуровневых системщиков" не готовили и готовить никогда не будут. Любой "низкоуровневый системщик" во всём мире готовится исключительно как "системный аналитик" и никак иначе, потому что разработка "базы", "платформы" — это наиболее ответственная часть в современном IT, по понятной причине — ошибки на этом уровне чудовищно дорогие из-за эффекта масштабирования.
Например, пользователю БД важно написать правильный SQL запрос к СУБД, но гораздо важнее, чтобы ЛЮБОЙ допустимый запрос правильно отработал на стороне самой СУБД.
IB>так что давай, расскажи мне чему учат на профильных специальностях
А то ты не знал?
Девочку из себя строить было не обязательно.
Пришлось расписать суть твоего манипулирования.
Ну, чтобы, не слишком гордо удалялся, угу.
IB>Буквально как в анекдоте — "там где вы учились, мы преподавали"
Хы-хы.
"Вы" не могли преподавать там, где я учился, иначе бы "вы" не палились насчёт "посмотри, сколько много закешировано планов".
Пока что ты дал понять, что не в курсе, в каком виде эти планы хранятся, какие там структуры данных и как можно на них сэкономить на порядок-другой, если дать достаточно времени на тождественные преобразования замкнутой системы уравнений РИ.
Да и вообще, чужая недогадливость — она всегда раздражает. У тебя достаточно опыта чтобы знать — современные СУБД часто не в состоянии отличить два простых запроса, отличающихся одной вшивой константой в предикате ограничения. Именно поэтому "руководство пользователя" СУБД прямо рекомендует превращать такие однотипные запросы в запросы с параметром и делать им prepare, иначе система будет динамически плодить всё новые и новые планы запросов, к количеству которых ты апеллируешь. Добавь к этому тот факт, что СУБД запросто считает разными даже совершенно идентичные по-сути запросы, но с небольшой переформулировкой выражений в нём, т.е. плодит и плодит в том числе идентичные наборы планов, сцуко. Кароч, из-за всей абсурдности этого цирка я уже не знаю, смеяться мне или плакать и куда я вообще попал? ))
С одной стороны (мне казалось это очевидным для всех), при статической компиляции запросы с параметрами + prepare будут как мёртвому припарка, бо и без подсказок со стороны сопливых компилятор прекрасно разберётся. Причём, он разберётся и найдёт идентичности даже там, где ты и вообразить не мог, даже у тех запросов или частей их, которые никак не кажутся похожими.
С другой стороны, мне тут в лицо аргументы – идите почитайте про "prepare". ))
«Вот вам букварь» — мой ответ.
Но хрен с ним, идём далее.
Когда речь о компиляции алгоритма над константными структурами данных, то сами данные часто исчезают – превращаются тупо в код (раскрутка циклов и рекурсивных вызовов и всё это опять рекурсивно). Тем самым убирается еще один уровень интерпретирования над данными, который практически всегда есть даже в самой-пресамой нейтивной программе над неконстантными данными. Но мы-то говорим о константных данных, т.е. которые можно превращать в код (всё мн-во запросов и планов по ним).
Или еще пример – во многих "больших" системах в избытке наличествуют данные справочного характера, причём, некоторые из этих данных меняются очень редко или не меняются никогда (для примера – виды ордеров, т.е. такие данные, которые бесполезно менять без изменений в коде, т.е. для данного состояния кода они, по-сути, не меняются). Т.е., хватает таблиц небольшого размера, которые можно считать эдаким способом подробного описания enum-ов, просто на стороне базы, а не на клиенте. Всю эту шелуху тоже можно убрать нафик из таблиц (убрать сами таблицы), тупо инлайня код с их участием. Подобных мелочей хватает, но они могут кардинально влиять на происходящее, делая ассоциации "бесплатными" — например, вместо ID такого enum в других таблицах можно хранить физическое смещение на структуру в сегменте константных данных скомпиллированного бинарника. И такий мелочей, стоит только ногтём подцепить, — овердохрена.
Так же я давал оценку «распухания кода» (дополнительного объема) и сравнивал сие с объемом кода, который требуется для работы нынешней динамической системы (изымаемого объема). В динамической системе сегодня живёт и компилятор и интерпретатор, но это ж чудовищный объем функциональности, который и нафик не сдался скомпиллированному бинарнику.
И пусть мои прикидки грубые – это же лишь затравка для начала обсуждения, не? ))
Например, мне тут "напомнили", что в средней прикладной базе живёт пару тыс и более запросов. У меня и ответ давно имеется – там (грубо) 80% кода, считай, дублирует друг друга, а из оставшихся 20% половина является библиотечным слоем. Т.е. в случае компиляции дублирование исчезает и с библиотеками всяко получше, бо для статически собираемой системы объем данных свыше библиотек теоретически не ограничен – всё-равно в бинарь попадёт только используемое по-факту. Совсем другое дело для динамических систем, верно? Там особо не разбежишься с библиотеками.
V>> если предположить гипотеитческий вариант "все запросы известны заранее".
IB>Тот факт, что это гипотетическое предположение ошибочно, ты предпочел проигнорировать.
IB>Конечно, это же разрушит такую прекрасную теорию.
Если сам не понимаешь — спроси у коллег, хосподя, например, из вашей же rsdn team. Большинство из них (или даже все поголовно) прекрасно понимают, почему в случае статической компиляции "все запросы известны заранее" (С). И это вообще не теория, это постулат, условие существования такой системы.
V>>Мы были вынуждены писать учётные системы с бухгелтериями и прочий сугубо прикладной шлак уровня домохозяек с PHP, вместо того, чтобы участвовать в разработках самих технологий.
IB>В очередной раз советую тебе не судить обо всех по себе.
Я могу судить лишь по открытым источникам — по твоим статьям и по тому, что ты писал в форумы в те годы, когда был активен.
Кароч, это всё гребанный PHP, вид сбоку.
Я ХЗ как лично ты на это смотришь, но мне в те годы было стыдно каждую секунду такого времяпрепровождения. С тем же успехом можно было бесконечно админить линуха какие-нить. Тем более, что до этого уже довелось поработать ~6 лет именно системщиком, а не прикладником. И если ты сейчас более не занимаешься такой юзверской деятельностью, а сам участвуешь в разработке технологий, то я только за тебя порадуюсь, мне не жалко. Но в этот спор ты влез, увы, с колокольни махрового юзера с раненным ЧСВ.
>Ну теперь-то, надеюсь, вопросов будет поменьше, чего тебя тут большинство коллег игнорят, кроме rsdn team и "приближённых"?
IB>Ты опять находишь проблемы там где их нет. У меня нет проблем с тем, что меня кто-то игнорит, поэтому переставай пить коньяк по утрам
Я не сказал, что это «проблема», я просто констатирую факт – с тобой общаются не охотно. До тех пор, пока тебя это не беспокоит, это не является для тебя проблемой, разумеется.
V>>Специально за тобой не слежу, просто память хорошая,
IB>Ой, ну ладно, не оправдывайся, тут все свои )) Не стесняйся, я уже понял, что ты ко мне не равнодушен =)
Ровно в том же смысле не равнодушен, как и к нескольким сотням других коллег с этого сайта.
V>>Понятно, что у тебя с памятью похуже,
IB>Ты про меня уже целую биографию сочинил, хотя казалось бы, собрались пообсуждать недостатки SQL.
Не сочинил, мы с тобой уже общались несколько раз и все разы неудачно.
C тобой "пообсуждать" никак, бо происходящее всегда одинаково – не разобравшись влететь, понаставить диагнозов и гордо удалиться…
Никакие обсуждения тебя не интересуют, тебе подойдёт только «признание твоей правоты».
Как некий элемент традиции, вестимо.
Ну понятно, что "обсуждать" что-либо тут будет глупо, вот с тобой и не обсуждают.
Я ХЗ как некоторые не догоняют простых вещей, например, что сам по себе обмен аргументами в техническом споре – это нормально.
Но когда чел руинит спор, пресекая малейшие попытки обмена аргументами (причём, чаще не специально, а на твой манер — как слон в посудной лавке, что еще больше бесит, бо чел не видит себя со стороны), да еще если сам оказывается не прав технически (твои "невозможно знать заранее"), плюс еще ошибка детская – это всё составляет эпик фейл, аднака.
V>>Да, это всё учат в ВУЗ-ах профильных специальностей еще на 4-м курсе.
IB>В свое время, я этот курс читал в одном из не самых плохих вузов нашей прекрасной страны
«Этот курс»…
Этих курсов было как минимум 3 сильно разных.
Так перед кем ты опять пытаешься надуть своё ЧСВ?
Берем на те года специальности 2202 и 2204 — «автоматизированные системы обработки информации», «программное обеспечение выч. систем» или близкие к ним более поздние (с начальными индексами 6 и 7). Согласно твоих представлений о происходящем, скорее всего ты читал именно это. Бо именно в этих специальностях дают заметный упор на БД сугубо в прикладном плане. Они там, действительно, даже SQL учат, даже прямо на лекциях, а не на лабораторках и практических занятиях, ы-ы-ы.
Собсно, именно эти же специальности были и есть в том числе в виде среднего, а не высшего образования. Причём, как у нас, так и во всём мире — всякие колледжи и т.д., где тоже учат языкам программирования, в т.ч. SQL, а так же как правильно админить SQL-сервера, как запускать дефрагментацию индексов, зачем это надо и т.д. ))
Совсем другой курс читается на специальности 2201 «выч. машины, комплексы, сети» и близкой более поздней (после 94-го года) россыпи их. На этом курсе учат разрабатывать не прикладные БД, а именно СУБД. Учат не языку SQL, а навыкам разрабатывать языки, типа SQL, и весь механизм под ними.
Вот и получается у тебя смешная попытка манипулирования перед "остальными". Бо разве что вводный материал у этих курсов где-то похож, но целом м/у этими двумя направлениями чудовищная пропасть.
Чисто для сравнения (кому любопытно).
По первому направлению подготавливаются следующие специалисты (современное положение вещей):
• разработчик робототехнических систем и комплексов
• руководитель соответствующих подразделений
• разработчик систем управления и автоматики
• разработчик моделей обработки данных
• архитектор информационных систем
• специалист по проектированию и эксплуатации локальных вычислительных сетей
• специалист по эксплуатации информационных систем
• системный администратор
Вкратце — прикладуха и обслуживание ПО.
По второму:
• системный аналитик
• научный работник в области IT
• разработчик микропроцессорных систем
• проектировщик вычислительной техники
• специалист по наладке и ремонту выч. техники и их сетей
• системный программист
• инженер-системотехник
Вкратце — разработка программно-аппаратных выч. систем, "платформ", исследования в этом направлении.
На Западе это известное отличие читается как отличие "разработчика информационных систем" от "системного аналитика".
"Системный аналитик" – это наиболее близкий западный аналог нашей специальности «инженер-системотехник», где первое название в последние лет 10-15 всё охотнее применяется вместо второго.
Характерно (опять же, судя по обсуждениям тут) что эту специальность многие наши коллеги не понимают, часто путают с аналитиком предметной области – т.е. с «бизнес-аналитиком». А даже те, кто понимают эту специальность, часто невольно выхолащивают её до «сбора требований и постановки задачи», хотя это лишь малая часть деятельности. Просто одна из самых важных в IT (ИМХО), но всё-равно, это лишь некий этап разработки, а не она вся.
(да, тут на сайте регулярно замечаю даже за весьма неглупыми коллегами откровенно неудовлетворительные навыки формулирования проблематики, поубывав бы).
Системный аналитик не просто ставит задачу, а хорошо ориентируется в техническом аспекте её реализуемости, т.е. проводит поиск решений в ограничениях. Работа циничная и творческая одновременно. Именно для этого его взращивали как междисциплинарного специалиста, т.е. такого, который владеет как прикладными аспектами, так и системными, вплоть до особенностей железа, линий связи и т.д. Вплоть до того, что недостающее железо, линии передачи информации (сам их физический принцип или вплоть до способа модуляции несущих и поднесущих) или недостающее низкоуровневое программное обеспечение – всё это запросто реализуется в рамках проекта и я такое делал не раз.
"Прикладникам" такие фокусы не доступны, но прикладники и не разрабатывают движки БД, а обсуждалось именно это.
Известный "мем" — это как если прикладник в Дельфи не нашёл нужный ТКомпонент, то задача не имеет решения. ))
Собсно, нигде в мире отдельных "низкоуровневых системщиков" не готовили и готовить никогда не будут. Любой "низкоуровневый системщик" во всём мире готовится исключительно как "системный аналитик" и никак иначе, потому что разработка "базы", "платформы" — это наиболее ответственная часть в современном IT, по понятной причине — ошибки на этом уровне чудовищно дорогие из-за эффекта масштабирования.
Например, пользователю БД важно написать правильный SQL запрос к СУБД, но гораздо важнее, чтобы ЛЮБОЙ допустимый запрос правильно отработал на стороне самой СУБД.
IB>так что давай, расскажи мне чему учат на профильных специальностях
А то ты не знал?
Девочку из себя строить было не обязательно.
Пришлось расписать суть твоего манипулирования.
Ну, чтобы, не слишком гордо удалялся, угу.
IB>Буквально как в анекдоте — "там где вы учились, мы преподавали"
Хы-хы.
"Вы" не могли преподавать там, где я учился, иначе бы "вы" не палились насчёт "посмотри, сколько много закешировано планов".
Пока что ты дал понять, что не в курсе, в каком виде эти планы хранятся, какие там структуры данных и как можно на них сэкономить на порядок-другой, если дать достаточно времени на тождественные преобразования замкнутой системы уравнений РИ.
Да и вообще, чужая недогадливость — она всегда раздражает. У тебя достаточно опыта чтобы знать — современные СУБД часто не в состоянии отличить два простых запроса, отличающихся одной вшивой константой в предикате ограничения. Именно поэтому "руководство пользователя" СУБД прямо рекомендует превращать такие однотипные запросы в запросы с параметром и делать им prepare, иначе система будет динамически плодить всё новые и новые планы запросов, к количеству которых ты апеллируешь. Добавь к этому тот факт, что СУБД запросто считает разными даже совершенно идентичные по-сути запросы, но с небольшой переформулировкой выражений в нём, т.е. плодит и плодит в том числе идентичные наборы планов, сцуко. Кароч, из-за всей абсурдности этого цирка я уже не знаю, смеяться мне или плакать и куда я вообще попал? ))
С одной стороны (мне казалось это очевидным для всех), при статической компиляции запросы с параметрами + prepare будут как мёртвому припарка, бо и без подсказок со стороны сопливых компилятор прекрасно разберётся. Причём, он разберётся и найдёт идентичности даже там, где ты и вообразить не мог, даже у тех запросов или частей их, которые никак не кажутся похожими.
С другой стороны, мне тут в лицо аргументы – идите почитайте про "prepare". ))
«Вот вам букварь» — мой ответ.
Но хрен с ним, идём далее.
Когда речь о компиляции алгоритма над константными структурами данных, то сами данные часто исчезают – превращаются тупо в код (раскрутка циклов и рекурсивных вызовов и всё это опять рекурсивно). Тем самым убирается еще один уровень интерпретирования над данными, который практически всегда есть даже в самой-пресамой нейтивной программе над неконстантными данными. Но мы-то говорим о константных данных, т.е. которые можно превращать в код (всё мн-во запросов и планов по ним).
Или еще пример – во многих "больших" системах в избытке наличествуют данные справочного характера, причём, некоторые из этих данных меняются очень редко или не меняются никогда (для примера – виды ордеров, т.е. такие данные, которые бесполезно менять без изменений в коде, т.е. для данного состояния кода они, по-сути, не меняются). Т.е., хватает таблиц небольшого размера, которые можно считать эдаким способом подробного описания enum-ов, просто на стороне базы, а не на клиенте. Всю эту шелуху тоже можно убрать нафик из таблиц (убрать сами таблицы), тупо инлайня код с их участием. Подобных мелочей хватает, но они могут кардинально влиять на происходящее, делая ассоциации "бесплатными" — например, вместо ID такого enum в других таблицах можно хранить физическое смещение на структуру в сегменте константных данных скомпиллированного бинарника. И такий мелочей, стоит только ногтём подцепить, — овердохрена.
Так же я давал оценку «распухания кода» (дополнительного объема) и сравнивал сие с объемом кода, который требуется для работы нынешней динамической системы (изымаемого объема). В динамической системе сегодня живёт и компилятор и интерпретатор, но это ж чудовищный объем функциональности, который и нафик не сдался скомпиллированному бинарнику.
И пусть мои прикидки грубые – это же лишь затравка для начала обсуждения, не? ))
Например, мне тут "напомнили", что в средней прикладной базе живёт пару тыс и более запросов. У меня и ответ давно имеется – там (грубо) 80% кода, считай, дублирует друг друга, а из оставшихся 20% половина является библиотечным слоем. Т.е. в случае компиляции дублирование исчезает и с библиотеками всяко получше, бо для статически собираемой системы объем данных свыше библиотек теоретически не ограничен – всё-равно в бинарь попадёт только используемое по-факту. Совсем другое дело для динамических систем, верно? Там особо не разбежишься с библиотеками.
V>> если предположить гипотеитческий вариант "все запросы известны заранее".
IB>Тот факт, что это гипотетическое предположение ошибочно, ты предпочел проигнорировать.
IB>Конечно, это же разрушит такую прекрасную теорию.
Если сам не понимаешь — спроси у коллег, хосподя, например, из вашей же rsdn team. Большинство из них (или даже все поголовно) прекрасно понимают, почему в случае статической компиляции "все запросы известны заранее" (С). И это вообще не теория, это постулат, условие существования такой системы.
V>>Мы были вынуждены писать учётные системы с бухгелтериями и прочий сугубо прикладной шлак уровня домохозяек с PHP, вместо того, чтобы участвовать в разработках самих технологий.
IB>В очередной раз советую тебе не судить обо всех по себе.
Я могу судить лишь по открытым источникам — по твоим статьям и по тому, что ты писал в форумы в те годы, когда был активен.
Кароч, это всё гребанный PHP, вид сбоку.
Я ХЗ как лично ты на это смотришь, но мне в те годы было стыдно каждую секунду такого времяпрепровождения.
С тем же успехом можно было бесконечно админить линуха какие-нить. Тем более, что до этого уже довелось поработать ~6 лет именно системщиком, а не прикладником. И если ты сейчас более не занимаешься такой юзверской деятельностью, а сам участвуешь в разработке технологий, то я только за тебя порадуюсь, мне не жалко. Но в этот спор ты влез, увы, с колокольни махрового юзера с раненным ЧСВ.