У меня самые популярные — Solution Explorer, Test Explorer.
Если бы нормально работала интеграция с git+jira, то в этом списке был бы и Team Explorer, которым я часто пользовался, когда работал с TFS.
В output иногда заглядываю, когда билд падает, да и то не каждый раз.
Про сворачивание итогов билда проекта до одной строки — было когда-то, очень давно, сейчас ничего подобного найти не могу, а разглядывать портянку не хочу.
Про фильтрация по проектам — у студии есть режим вывода «Build Order» — там уже все записи по каждому проекту сгруппированы.
Покажу Вам одну картинку. Думаю это закроет дискуссию, что лучше «текст» или «не текст».
По картинке не пойму, какова цель такого отображения.
Но то, о чём я говорю, можно сделать на html. Там и активные элементы и текст, который можно выделить.
Вы можете менять цвета для любого сообщения (или вообще их убирать), просто кликая мышкой на поле с временной меткой.
Это не интуитивно. А экспортировать/импортировать цветовую схему можно?
На сайте это уже описано текстом. Этого никто не читает. Ну или почти никто…
Да потому что читать нечего. Есть список фич, но не понятно ни как они работают, ни как ими пользоваться, ни как это настраивать.
Я взрослый человек, и понимаю, что не смогу убедить 100% тех к кому обращаюсь.
Потому и не ставлю себе такую задачу.
Ну так может и не делать таких громких заявлений, типа «Once you see this extension, you will forget standard output window»?
Я, например, не знаю чего то более используемого чем «Output».
Так уже честнее — этот инструмент популярен у вас лично.
Ок, тогда вопрос, а какие задачи вы с его помощью решаете? Я иногда ищу там ошибки компиляции, очень редко посматриваю вывод трассировки.
1. Группировки по проектам нет и не будет. Не вижу в этом смысла.
А мне кажется удобным по умолчанию видеть при сборке только статус каждого проекта. Остальная портянка только мешает, как бы она не была раскрашена.
4. Насчет «ошибок командной строки» не понял вопроса. Поясните пожалуйста, что имеется в виду.
Для сборки некоторых типов проектов студия может вызывать дополнительные команды. Например — вызов nodejs. Вывод этих команд также попадает в окно вывода, а результат билда оценивается по коду возврата этой команды.
Я первый, кто стал утверждать что «Output» — это НЕ текст. Кто окажется прав, покажет время.
Сильно утверждение :). Ближе к правде — там не только текст. Но текст более универсален как способ представления. И я знаю способ, как можно совместить дополнительные возможности с текстовым представлением.
6. Настройки появятся для дополнительного функционала, где это будет обосновано. Текущий функционал настроек не требует.
Очень сильное утверждение. Вы уверены, что выбранная вами цветовая гамма идеальна?
Имхо, окно вывода называть самым популярным инструментом — перебор.
Тем более называть эволюцией кастомную раскраску…
Хотя сама попытка существенно улучшить это окно — хорошая идея.
Вот есть ли у вас группировка событий в окне вывода при сборке по проектам? Так, чтобы можно было по умолчанию оставить только одну строку с результатом билда, и раскрывать детали по клику?
Есть возможность одним кликом включать/выключать показ только ошибок, предупреждений?
А учитываются ли как ошибки неудачные вызовы утилит командной строки?
А почему нельзя нормально копировать текст, как в обычном окне вывода?
Настроек нет совсем на столько, что стандартном меню настроек есть только текст лицензии?
Где нибудь можно почитать описание фич, настроек, планов развития?
Отвечая на цитату:
Once you see this extension, you will forget standard output window
Нет, мне стандартное окошко вывода с имеющимся плагинами удобнее.
Ну, свобода воли как раз про возможность жить так, как хочется :)
А что касается экспериментов со свободой воли — это вы не туда копаете. Эксперимент Либета говорит исключительно про скорость протекания нервных процессов, да и то не всех и не всегда. Из вашей первой ссылки:
Вопреки ожиданиям приборы показали такую последовательность событий:
— сначала появлялся потенциал готовности;
— потом примерно через 350 мс испытуемый сознательно принимал решение пошевелить кистью (это регистрировалось временем на циферблате перед ним);
— через примерно 100 мс шел сигнал от запястья кисти.
Т.е. до момента сознательного решения человека, его мозг уже активировался.
Этому есть тривиальное объяснение: таки человек заранее готовится к будущему активному действию, потом принимал решение, потом действовал.
Но почему-то делается такой вывод:
Выходит, что наше принимаемое сознательное решение является лишь следствием мозговой бессознательной активности определенных участков мозга.
Но вот с чего бы? Очень хотелось продвинуть эту теорию и для этого натягивали на неё факты?
Если почитать про другие его эксперименты, то там картинка аналогичная — множественные попытки свести сознательную деятельность к некоторым нервным активностям в мозгу, хотя до сих пор никто не знает, как именно в мозгу работает мысль.
И отдельно про 15-20 секунд… Вы когда нибудь играли в быстрые спортивные игры? Бадминтон, настольный теннис? Там порой на анализ новой информации, принятие решения и активное действие тратится меньше секунды, а игроков два или больше, и скорость их сознательной деятельности, можно сказать, что фиксируется независимым наблюдателем — видеокамерой.
И если вы живёте с отставанием в 15 секунд — то это именно вы «тормозите» :), хотя, скорее всего, вера в эти секунды есть последствие внутренней потребности снять с себя ответственность за некоторые свои поступки.
Вот запоминают джуны всякие картинки, а суть всё равно утекает. Далее канонического описания уйти не могут.
Самый банальный вопрос, на котором многие тупят на собеседовании — что будет, если среди значений попадётся null?
И хорошо, если сумеет вспомнить, что по стандарту null не равен ничему. Но сумеет ли домыслить результат?
Часто может для left join получить вот такую табличку:
А должен был бы получить:
И даже если нарисует, поймёт ли, почему так? Что там ещё сокрыто под этими null-ми?
Куда нагляднее, если добавить ещё один столбец с данными и посмотреть на результат (кстати, многие осилив пример из статьи, сливаются на таком простом усложнении):
CREATE TABLE t1 (id int, v varchar(1));
CREATE TABLE t2 (id int, v varchar(1));
INSERT INTO t1
values
(1, 'a'),
(null, 'b'),
(1, 'c'),
(6, 'd'),
(5, 'e'),
(null, 'f');
INSERT INTO t2
VALUES
(1, 'a'),
(1, 'b'),
(2, 'c'),
(null, 'd'),
(3, 'e'),
(5, 'f'),
(null, 'g');
SELECT t1.id, t2.id
FROM t1
LEFT JOIN t2
ON t1.id = t2.id;
SELECT t1.v, t2.v
FROM t1
LEFT JOIN t2
ON t1.id = t2.id;
Я говорю о возможности и желании делать выводы. Я поучаствовал в обсуждении предыдущей статьи — ответа не дождался…
А с аргументацией в комментариях так весело потому, что вы замахиваетесь на основы, но сами не приводите внятной аргументации. Что-то где-то понадёргано, как-то в кучу свалено… Тут даже не понятно, что комментить.
Зато оценка явно сигнализирует, что ваши материалы не годны для публикации тут. Либо менять площадку, либо брать другие темы и лучше готовить статьи. Это вроде логичный вывод?
Ну, начнём с того, что вы, Владимир, видимо забыли в этой заметке рассказать суть вопроса, ради которого писали оную… Худо-бедно можно понять, что имеется в виду под сложными БД, но какую именно реальную практическую проблему вы хотите решить — решительно не понятно.
Много слов про историю вопроса, а цель писания где? Неужто только вот в этом: «Хватит играть в реляционные погремушки!»?
Так, а здесь что? А здесь проснулся Mikluho, который изрёк гениальнейшую мысль: «реляционные БД коммерчески более успешны для пользователей». Интересно, кто, когда, о чём это быдло (в смысле, пользователей) спрашивал? Ну хоть раз! А ещё он фактически процитировал мою заметку, сказав про «достаточно простой язык запросов» — работать со сложными данными стадо даже и не рыпается! А дальше понёс клиническую ахинею про «скорость работы с данными» и «персистентные хранилища», которые «до сих пор не слишком быстры на фоне объёмов данных». Так ВАЛИТЬ НАДО НАХЕР от этих долбаных таблиц! Не говоря уже про эти долбаные «сбалансированные деревья поиска». Хули вы там «искать» собрались, бараны? Тем и хороша графовая модель, что там ничего искать не надо! Ссылку кинул — и порядок!
Во-первых, а зачем спрашивать, если пользователь голосует деньгами?
Во-вторых, если вдруг не понятно, пользователь — это не тот, кто счета в формочки вбивает, а компания, которая для своих нужд покупает СУБД. А посему совсем не уместно упоминать тут какие-то стада, ибо они нам и вам зарплату платят.
В-третьих, со сложными БД они таки не пытаются, а просто работают. И выбирают СУБД в том числе из коммерческих соображений.
Далее вы опять занимаете любимую позицию «кто со мной не согласен — быдло, всё, кроме моих мыслей — ахинея» :)
Но так уж и быть, попробую прояснить то, что большинству понятно, а вам невдомёк. Ну или вы, быть может, снизойдёте с небес да проясните, как в вашей идеологии решается конкретная задача.
Есть у нас некая БД, в которой лежат финансовые отчёты. Формат данных задаётся снаружи всякими международными или более локальными нормами. Отчётных форм много, собираются они с разной периодичностью, многие формируются в определённых административно-территориальных разрезах. А ещё состав или способ вычисления показателей в отчётах иногда меняется по требованиям внешних организаций (например центробанка). Каждая форма характеризуется набором статических атрибутов и наборов табличных данных (уж от этих таблиц нику не деться). Часть данных в этих формах опираются на справочники, которые иногда меняются, т.е. в один период времени во всех отчётах должен использовать один набор значений конкретного справочника. Это позволяет, в частности, сравнивать данные из разных отчётов и делать аналитические и сводные отчёты.
В такой картинке у конкретного отчёта есть несколько базовых атрибутов (т.е. общих для всех отчётов), таких как: «название отчётной формы», «версия», «отчётный период», «источник», «дата формирования», «автор». Набор остальных данных в отчёте зависит от формы и её версии.
Конечные пользователи, конечно, хотят видеть отчёты в табличном представлении. И хотят видеть списки отчётов, отобранных по определённым атрибутам. И хотят, чтобы отчёт им на просмотр открывался быстро, т. е. кликнули в списке на нужный — и через пару секунд видят его в удобном табличном представлении, даже если в нём тысячи строк. А ещё они хотят, чтобы сводные и аналитические отчёты быстро вытягивали из БД значение всех показателей конкретных финансовых отчётов. Даже если эти отчёты из сильно разных дат.
Итого, типичные запросы к БД:
Показать список отчётов с разным набором фильтров и сортировок по базовым атрибутам.
Показать все данные конкретного экземпляра отчёта.
Собрать новый отчёт из данных нескольких других отчётов — отчёты отбираются условиями по базовым атрибутам, вычисляемые показатели вычисляются по справочникам — т.е. берутся из разных отчётов строчки, где определённый атрибут имеет одно и то же значение, и в формулу, вычисляющую значение итогового отчёта, берутся значения определённых атрибутов отобранных строк.
Итого, имеем терабайты или даже петабайты данных и потребность быстро делать типовые выборки. И, конечно, это всё должно быть дёшево. Как это сделать на реляционке, я понимаю. И даже понимаю, почему оно будет работать быстро. А вот как это реализовать на графовой БД и чего это будет стоить — не представляю.
Mikluho
Это мне напомнило опыт из 2000-го
Лапуль, может, не надо тут про «опыт» от MS SQL? Статья посвящена как раз тому, чтобы ВЫШВЫРНУТЬ К ЧЕРТЯМ СВИНЯЧЬИМ это вонючее «табличное хранение»! И своё долбаное «объектное хранилище» засуньте туда же! Какой дебил когда сказал, что «в табличном хранилище — быстрый доступ»?! С КАКОГО БОДУНА? Быстрый доступ — это В ГРАФОВЫХ базах данных! Причём графовых НА УРОВНЕ ЯДРА, а не с этой вашей долбаной «эмуляцией»!
да, апп-сервер мог модифицировать структуру БД
Да?! А вот с этого места поподробнее, плиз! Кто там что и как мог «модифицировать»? :spy:
Я вам не «лапуль»! Спрячьте ваше свинское фамильярство куда поглубже, можно даже в место, куда не заглядывает солнце :)
И таки да, выборка набора однородных данных в таблице быстрее всего, т. к. движок СУБД может получить эти данные, читая с хранилища блоки предопределённого размера, часто линейно.
«Модифицировать» — это значит, что наш апп-сервер при добавлении атрибута к сущности добавлял столбец в таблицу. Понятное дело, удалять и модифицировать столбцы он не пытался :).
И да, пока вы не объясните, как ваши графовые бд делают удобно то, что нужно реальным массовым пользователям (т. е. тем, кто за всю эту красоту платит), вы балабол и теоретик, а не программист.
Ну дык! Есть же конкретные даты, когда «внешне-социальные условия» резко менялись. Дети, выросшие в новых условиях получали новые жизненные устои. И чем масшатбнее внешние изменения, тем заметнее феномен поколений.
Люди, пережившие ВОВ сильно отличаются от тех, кто родился сразу после…
И при этом, люди, родившиеся в начале 90-х в Москве сильно отличаются от сверстников из зауралья.
Плохо делать далеко идущие выводы на неявных обобщениях.
С одной стороны, феномен поколей существует, и у людей разных поколений изрядно отличаются жизненные ценности.
С другой стороны, «неадекваты» были всегда. Вспомните, например, приключения Шурика :)
Каждый конкретный индивид реализует сумму поведенческих паттернов.
По моим наблюдениям, главная причина поведенческих отличий поколений — сильно разное социальное воспитание. И при этом, чем дальше, тем менее однородна социальная среда…
Знание личностный особенностей, в том числе и поколенческих, помогает быстрее наладить контакт даже в довольно сложных случаях, выстроить эффективные коммуникации в долгосрочной перспективе.
Но сначала надо понять, а нужны ли эти коммуникации :)
В нашем примере у одной семантической сущности «Адрес» в БД могут одновременно присутствовать иерархический (графовый) и реляционный тип данных в различных её элементах. Но эти различия не мешают организации доступа к ним однородным путем: результатом пользовательского запроса по ключевому слову «Адрес» должны быть все адреса, существующие в БД, при этом они будут абсолютно неразличимы для конечного пользователя.
Это мне напомнило опыт из 2000-го, когда у нас было в БД (MS SQL) объектное хранилище, а для оптимизации хранения и доступа некоторые сущности вытаскивались в табличное хранение, но так как запросы к данным выполнялись через апп-сервер, для конечного потребителя ничего не менялось в запросе.
В объектном хранилище — гибкость (динамический список атрибутов, связи так же в атрибутах), но медленный доступ.
В табличном хранилище — быстрый доступ, но сложнее менять атрибутный состав сущности.
А следующий этап развития апп-сервера — на основании определённых метрик принимать решение о необходимости переноса сущности из объектного в табличное хранилище и автоматическое изменение атрибутного состава (да, апп-сервер мог модифицировать структуру БД).
Есть вариант проще — реляционные БД коммерчески более успешны для пользователей. Этот подход позволил воплотить в железе разумный компромисс между
а) универсальностью применения (таки почти всё можно описать),
б) удобством пользования (достаточно простой язык запросов) и
в) скоростью работы с данными (персистентные хранилища до сих пор не слишком быстры на фоне объёмов данных)
Конечно, есть случаи, когда более успешны другие решения — у них есть своя ниша.
Вы, как и автор, довольно настойчивы в переваливании вины с себя на некое анонимное быдло, что есть весьма удобная позиция, сходная небезызвестному д'артаньянству :)
Для сравнения, по моим наблюдениям, в обсуждениях этой и ещё нескольких последних статей автора, большая часть комментаторов как раз программисты. Эти программисты как раз пытаются понять, что за идею пытается донести автор, но после очередного ведра помоев, изливаемых автором, начинает пробивать «раздражение» «идеальным стилем» автора.
Отдельно выделяются комментаторы типа вас или Gerrero, которые выражают сочувствие источнику помоев, а не тем, на кого они изливаются. В таком раскладе странно ожидать массового одобрения.
Фокус в том, что неадекваты довольно быстро лишаются возможности минусовать. Я тут не мало срачей наблюдал, и случаев яростного отхабривания только из-за мнения исчезающе мало. Чаще всего наказывается форма коммуникации и настойчивость на откровенном идиотизме.
это антиконституционное нарушение свободы слова… И при этом тут же хватаются за кармамет в попытках заткнуть неугодных.
Вот только не надо забывать про разницу между цензурой и остракизмом. Цензура в руках владельца ресура, посредством которого кто-то пытается воспользоваться своей свободой слова. Остракизм суть самозащита общества от тех, кого они не хотят видеть и слышать.
В терминах Хабра, цензура может быть реализована через бан и прочие административные методы, а остракизм реализуется через карму.
Как уже многие сказали, вы сильно путаете своё восприятие людей с термином.
Почитайте хоть Википедию, не ограничивайте себя скупым «это психологический тип личности, замкнутого внутри своего собственного мира человека» — такая трактовка ведёт к заблуждениям.
Например, я — очень даже интроверт. Но в нашей команде разработки я один из самых коммуникабельных.
Уточнение — это если по работе. Если про путешествия и приключения — то я скорее слушать да комментировать буду. Но это особенности жизненного опыта. Если назревает эмоциональный кризис, поднимается градус страстей — то я же чаще всего тушу пожар. И, о ужас, иногда помогаю коллегам-экстравертам научиться более эффективным коммуникациям.
По моему опыту, как раз интроверт более стабилен и менее подвержен срыву при отвлекающих факторах типа «можно было подойти в случае необходимости и задать какой-то технический вопрос», но всё равно больше значение имеет невротизм.
1. Работать в «своё» время можно. Но надо чётко понимать, что это должно того стоить. Этого должно быть мало и оно должно быть компенсировано. Премия, отгулы, возможность сделать что-то новое и интересное…
2. Иногда энтерпрайз — это ещё и устаревшее и закостеневшее всё :(, хотя часто поддаётся изменениям. Тут просто надо посмотреть до трудоустройства. В нынешних условиях энтерпрайз часто склонен к непрерывным изменениям при наличии хорошей стабильности. А ноют, на мой взгляд, чаще молодые, потому что боятся оков.
3. С точки зрения развития полезно поговорить с теми опытными, кто участвует в процессе подбора кадров. Можно узнать, какие навыки и технологии ценятся и где.
4. Так и да! Но если программирование действительно любишь, то можно не уходить совсем, а добавить в свою жизнь достаточно количество «реальной» жизни. То есть нужно увлечение, наполняющее эмоционально и/или физически. Многие выбирают спорт.
5. У молодых и модных часто ещё и неизвестно, взлетит ли. И даже если зарплата и правда будет больше, чем в скучных компаниях, то, наверняка не будет других бонусов, куда кроме дмс входит ещё уверенность в завтрашнем дне. Хотя опыта можно поднабраться в новых технологиях, порой :)
8. И даже одного кресла мало. Молодость организму не вернуть (медицина пока не осилила), а потому надо ввести в привычку здоровый образ жизни. Не обязательно не пить, не курить и всё время сидеть на диете. Нет, надо найти способ не сильно портить здоровье, но и чтобы не париться об этом. Таки снова регулярный спорт, менее вредные перекусы и т.д. Привычка быть здоровым — бесценна.
На всех не хватит великих задач, но и тем великим есть-пить, да более простые вещи автоматизировать надо, а для этого должны решаться менее великие задачи. А чтобы они эффективное решались и становились тормозом развития великих — в этих задачах тоже надо куму-то разбираться.
Если бы нормально работала интеграция с git+jira, то в этом списке был бы и Team Explorer, которым я часто пользовался, когда работал с TFS.
В output иногда заглядываю, когда билд падает, да и то не каждый раз.
Про сворачивание итогов билда проекта до одной строки — было когда-то, очень давно, сейчас ничего подобного найти не могу, а разглядывать портянку не хочу.
Про фильтрация по проектам — у студии есть режим вывода «Build Order» — там уже все записи по каждому проекту сгруппированы.
По картинке не пойму, какова цель такого отображения.
Но то, о чём я говорю, можно сделать на html. Там и активные элементы и текст, который можно выделить.
Это не интуитивно. А экспортировать/импортировать цветовую схему можно?
Да потому что читать нечего. Есть список фич, но не понятно ни как они работают, ни как ими пользоваться, ни как это настраивать.
Ну так может и не делать таких громких заявлений, типа «Once you see this extension, you will forget standard output window»?
Так уже честнее — этот инструмент популярен у вас лично.
Ок, тогда вопрос, а какие задачи вы с его помощью решаете? Я иногда ищу там ошибки компиляции, очень редко посматриваю вывод трассировки.
А мне кажется удобным по умолчанию видеть при сборке только статус каждого проекта. Остальная портянка только мешает, как бы она не была раскрашена.
Для сборки некоторых типов проектов студия может вызывать дополнительные команды. Например — вызов nodejs. Вывод этих команд также попадает в окно вывода, а результат билда оценивается по коду возврата этой команды.
Сильно утверждение :). Ближе к правде — там не только текст. Но текст более универсален как способ представления. И я знаю способ, как можно совместить дополнительные возможности с текстовым представлением.
Очень сильное утверждение. Вы уверены, что выбранная вами цветовая гамма идеальна?
Это хорошо для фэйсбучека, на сайте проекта лучше текстом.
И как это соотносится с заглавным утверждением на страничке расширения?
Тем более называть эволюцией кастомную раскраску…
Хотя сама попытка существенно улучшить это окно — хорошая идея.
Вот есть ли у вас группировка событий в окне вывода при сборке по проектам? Так, чтобы можно было по умолчанию оставить только одну строку с результатом билда, и раскрывать детали по клику?
Есть возможность одним кликом включать/выключать показ только ошибок, предупреждений?
А учитываются ли как ошибки неудачные вызовы утилит командной строки?
А почему нельзя нормально копировать текст, как в обычном окне вывода?
Настроек нет совсем на столько, что стандартном меню настроек есть только текст лицензии?
Где нибудь можно почитать описание фич, настроек, планов развития?
Отвечая на цитату:
Нет, мне стандартное окошко вывода с имеющимся плагинами удобнее.
А что касается экспериментов со свободой воли — это вы не туда копаете. Эксперимент Либета говорит исключительно про скорость протекания нервных процессов, да и то не всех и не всегда. Из вашей первой ссылки:
Этому есть тривиальное объяснение: таки человек заранее готовится к будущему активному действию, потом принимал решение, потом действовал.
Но почему-то делается такой вывод:
Но вот с чего бы? Очень хотелось продвинуть эту теорию и для этого натягивали на неё факты?
Если почитать про другие его эксперименты, то там картинка аналогичная — множественные попытки свести сознательную деятельность к некоторым нервным активностям в мозгу, хотя до сих пор никто не знает, как именно в мозгу работает мысль.
И отдельно про 15-20 секунд… Вы когда нибудь играли в быстрые спортивные игры? Бадминтон, настольный теннис? Там порой на анализ новой информации, принятие решения и активное действие тратится меньше секунды, а игроков два или больше, и скорость их сознательной деятельности, можно сказать, что фиксируется независимым наблюдателем — видеокамерой.
И если вы живёте с отставанием в 15 секунд — то это именно вы «тормозите» :), хотя, скорее всего, вера в эти секунды есть последствие внутренней потребности снять с себя ответственность за некоторые свои поступки.
Самый банальный вопрос, на котором многие тупят на собеседовании — что будет, если среди значений попадётся null?
И хорошо, если сумеет вспомнить, что по стандарту null не равен ничему. Но сумеет ли домыслить результат?
Часто может для left join получить вот такую табличку:
А должен был бы получить:
И даже если нарисует, поймёт ли, почему так? Что там ещё сокрыто под этими null-ми?
Куда нагляднее, если добавить ещё один столбец с данными и посмотреть на результат (кстати, многие осилив пример из статьи, сливаются на таком простом усложнении):
Первый select вернёт данные для второй картинки:
А что вернёт второй select?
Что в виде наглядной таблички выглядит так:
А с аргументацией в комментариях так весело потому, что вы замахиваетесь на основы, но сами не приводите внятной аргументации. Что-то где-то понадёргано, как-то в кучу свалено… Тут даже не понятно, что комментить.
Зато оценка явно сигнализирует, что ваши материалы не годны для публикации тут. Либо менять площадку, либо брать другие темы и лучше готовить статьи. Это вроде логичный вывод?
Что очередная трешёвая идея — это не удивительно… Удивительно упорство автора…
Newton2 — скажите, зачем вы это всё пишете?
Каждый раз, получаете заслуженные минуса, сливаетесь из дискуссии и порождаете новый опус?
Ну, начнём с того, что вы, Владимир, видимо забыли в этой заметке рассказать суть вопроса, ради которого писали оную… Худо-бедно можно понять, что имеется в виду под сложными БД, но какую именно реальную практическую проблему вы хотите решить — решительно не понятно.
Много слов про историю вопроса, а цель писания где? Неужто только вот в этом: «Хватит играть в реляционные погремушки!»?
Во-первых, а зачем спрашивать, если пользователь голосует деньгами?
Во-вторых, если вдруг не понятно, пользователь — это не тот, кто счета в формочки вбивает, а компания, которая для своих нужд покупает СУБД. А посему совсем не уместно упоминать тут какие-то стада, ибо они нам и вам зарплату платят.
В-третьих, со сложными БД они таки не пытаются, а просто работают. И выбирают СУБД в том числе из коммерческих соображений.
Далее вы опять занимаете любимую позицию «кто со мной не согласен — быдло, всё, кроме моих мыслей — ахинея» :)
Но так уж и быть, попробую прояснить то, что большинству понятно, а вам невдомёк. Ну или вы, быть может, снизойдёте с небес да проясните, как в вашей идеологии решается конкретная задача.
Есть у нас некая БД, в которой лежат финансовые отчёты. Формат данных задаётся снаружи всякими международными или более локальными нормами. Отчётных форм много, собираются они с разной периодичностью, многие формируются в определённых административно-территориальных разрезах. А ещё состав или способ вычисления показателей в отчётах иногда меняется по требованиям внешних организаций (например центробанка). Каждая форма характеризуется набором статических атрибутов и наборов табличных данных (уж от этих таблиц нику не деться). Часть данных в этих формах опираются на справочники, которые иногда меняются, т.е. в один период времени во всех отчётах должен использовать один набор значений конкретного справочника. Это позволяет, в частности, сравнивать данные из разных отчётов и делать аналитические и сводные отчёты.
В такой картинке у конкретного отчёта есть несколько базовых атрибутов (т.е. общих для всех отчётов), таких как: «название отчётной формы», «версия», «отчётный период», «источник», «дата формирования», «автор». Набор остальных данных в отчёте зависит от формы и её версии.
Конечные пользователи, конечно, хотят видеть отчёты в табличном представлении. И хотят видеть списки отчётов, отобранных по определённым атрибутам. И хотят, чтобы отчёт им на просмотр открывался быстро, т. е. кликнули в списке на нужный — и через пару секунд видят его в удобном табличном представлении, даже если в нём тысячи строк. А ещё они хотят, чтобы сводные и аналитические отчёты быстро вытягивали из БД значение всех показателей конкретных финансовых отчётов. Даже если эти отчёты из сильно разных дат.
Итого, типичные запросы к БД:
Показать список отчётов с разным набором фильтров и сортировок по базовым атрибутам.
Показать все данные конкретного экземпляра отчёта.
Собрать новый отчёт из данных нескольких других отчётов — отчёты отбираются условиями по базовым атрибутам, вычисляемые показатели вычисляются по справочникам — т.е. берутся из разных отчётов строчки, где определённый атрибут имеет одно и то же значение, и в формулу, вычисляющую значение итогового отчёта, берутся значения определённых атрибутов отобранных строк.
Итого, имеем терабайты или даже петабайты данных и потребность быстро делать типовые выборки. И, конечно, это всё должно быть дёшево. Как это сделать на реляционке, я понимаю. И даже понимаю, почему оно будет работать быстро. А вот как это реализовать на графовой БД и чего это будет стоить — не представляю.
Я вам не «лапуль»! Спрячьте ваше свинское фамильярство куда поглубже, можно даже в место, куда не заглядывает солнце :)
И таки да, выборка набора однородных данных в таблице быстрее всего, т. к. движок СУБД может получить эти данные, читая с хранилища блоки предопределённого размера, часто линейно.
«Модифицировать» — это значит, что наш апп-сервер при добавлении атрибута к сущности добавлял столбец в таблицу. Понятное дело, удалять и модифицировать столбцы он не пытался :).
И да, пока вы не объясните, как ваши графовые бд делают удобно то, что нужно реальным массовым пользователям (т. е. тем, кто за всю эту красоту платит), вы балабол и теоретик, а не программист.
Люди, пережившие ВОВ сильно отличаются от тех, кто родился сразу после…
И при этом, люди, родившиеся в начале 90-х в Москве сильно отличаются от сверстников из зауралья.
С одной стороны, феномен поколей существует, и у людей разных поколений изрядно отличаются жизненные ценности.
С другой стороны, «неадекваты» были всегда. Вспомните, например, приключения Шурика :)
Каждый конкретный индивид реализует сумму поведенческих паттернов.
По моим наблюдениям, главная причина поведенческих отличий поколений — сильно разное социальное воспитание. И при этом, чем дальше, тем менее однородна социальная среда…
Знание личностный особенностей, в том числе и поколенческих, помогает быстрее наладить контакт даже в довольно сложных случаях, выстроить эффективные коммуникации в долгосрочной перспективе.
Но сначала надо понять, а нужны ли эти коммуникации :)
Это мне напомнило опыт из 2000-го, когда у нас было в БД (MS SQL) объектное хранилище, а для оптимизации хранения и доступа некоторые сущности вытаскивались в табличное хранение, но так как запросы к данным выполнялись через апп-сервер, для конечного потребителя ничего не менялось в запросе.
В объектном хранилище — гибкость (динамический список атрибутов, связи так же в атрибутах), но медленный доступ.
В табличном хранилище — быстрый доступ, но сложнее менять атрибутный состав сущности.
А следующий этап развития апп-сервера — на основании определённых метрик принимать решение о необходимости переноса сущности из объектного в табличное хранилище и автоматическое изменение атрибутного состава (да, апп-сервер мог модифицировать структуру БД).
а) универсальностью применения (таки почти всё можно описать),
б) удобством пользования (достаточно простой язык запросов) и
в) скоростью работы с данными (персистентные хранилища до сих пор не слишком быстры на фоне объёмов данных)
Конечно, есть случаи, когда более успешны другие решения — у них есть своя ниша.
Для сравнения, по моим наблюдениям, в обсуждениях этой и ещё нескольких последних статей автора, большая часть комментаторов как раз программисты. Эти программисты как раз пытаются понять, что за идею пытается донести автор, но после очередного ведра помоев, изливаемых автором, начинает пробивать «раздражение» «идеальным стилем» автора.
Отдельно выделяются комментаторы типа вас или Gerrero, которые выражают сочувствие источнику помоев, а не тем, на кого они изливаются. В таком раскладе странно ожидать массового одобрения.
Вот только не надо забывать про разницу между цензурой и остракизмом. Цензура в руках владельца ресура, посредством которого кто-то пытается воспользоваться своей свободой слова. Остракизм суть самозащита общества от тех, кого они не хотят видеть и слышать.
В терминах Хабра, цензура может быть реализована через бан и прочие административные методы, а остракизм реализуется через карму.
Почитайте хоть Википедию, не ограничивайте себя скупым «это психологический тип личности, замкнутого внутри своего собственного мира человека» — такая трактовка ведёт к заблуждениям.
Например, я — очень даже интроверт. Но в нашей команде разработки я один из самых коммуникабельных.
Уточнение — это если по работе. Если про путешествия и приключения — то я скорее слушать да комментировать буду. Но это особенности жизненного опыта. Если назревает эмоциональный кризис, поднимается градус страстей — то я же чаще всего тушу пожар. И, о ужас, иногда помогаю коллегам-экстравертам научиться более эффективным коммуникациям.
По моему опыту, как раз интроверт более стабилен и менее подвержен срыву при отвлекающих факторах типа «можно было подойти в случае необходимости и задать какой-то технический вопрос», но всё равно больше значение имеет невротизм.
Но позволю чуть дополнить :)
1. Работать в «своё» время можно. Но надо чётко понимать, что это должно того стоить. Этого должно быть мало и оно должно быть компенсировано. Премия, отгулы, возможность сделать что-то новое и интересное…
2. Иногда энтерпрайз — это ещё и устаревшее и закостеневшее всё :(, хотя часто поддаётся изменениям. Тут просто надо посмотреть до трудоустройства. В нынешних условиях энтерпрайз часто склонен к непрерывным изменениям при наличии хорошей стабильности. А ноют, на мой взгляд, чаще молодые, потому что боятся оков.
3. С точки зрения развития полезно поговорить с теми опытными, кто участвует в процессе подбора кадров. Можно узнать, какие навыки и технологии ценятся и где.
4. Так и да! Но если программирование действительно любишь, то можно не уходить совсем, а добавить в свою жизнь достаточно количество «реальной» жизни. То есть нужно увлечение, наполняющее эмоционально и/или физически. Многие выбирают спорт.
5. У молодых и модных часто ещё и неизвестно, взлетит ли. И даже если зарплата и правда будет больше, чем в скучных компаниях, то, наверняка не будет других бонусов, куда кроме дмс входит ещё уверенность в завтрашнем дне. Хотя опыта можно поднабраться в новых технологиях, порой :)
8. И даже одного кресла мало. Молодость организму не вернуть (медицина пока не осилила), а потому надо ввести в привычку здоровый образ жизни. Не обязательно не пить, не курить и всё время сидеть на диете. Нет, надо найти способ не сильно портить здоровье, но и чтобы не париться об этом. Таки снова регулярный спорт, менее вредные перекусы и т.д. Привычка быть здоровым — бесценна.