Ситуация с пропиетарными БД

тебе админить или программировать

Вот пока я думаю. НА моей социологической практике скорее «админить», поскольку вот в недавне социологическом проекте отвечал за то, чтобы база данных респондентов не рушилась и работала на выдачу данных.

Но если получится, то и программировать :)))

И как показывает практика, не каждый способен любить СУБД в принципе.

Её не надо любить. Это только труЪ ынтырпрайз-ораклисты возводят ежедневное оральное-ректальное взаимодействие со своим информационным копроративным Богом в ранг неразделенной содомической любви с элементами переходящего гедонистического доминирования.

А суть сегодня такова, что объемы растут, а CAP-теорему никто не отменял. И там, где вчера была хоумпага с LAMP-сервером, завтра придется всё переписывать на... что-то более лучшее. Быстро, качественно и недорого, как это не печально. И все эти модные «ACID с транзакциями», наклейки с 9999.999999% хреновой надежности и прочего уйдут на третий план везде, кроме банковского/бухгалтерского дела. Во имя масштабирования, дешевизны и простоты обслуживания, быстрого наполнения, поиска, кластерного анализа и машинного обучения (рекомендации, выявления связностей и т.д.).

Короче, SQLящих слушать не надо. Они доживут свои дни до пенсии, и уйдут вместе со своими тормозными немасштабируемыми говноподелиями на кладбище. Если хочешь смотреть на завтрашний день, то SQL — это максимум уходящий сегодняшний день, приближающийся к полуночи.

Короче, SQLящих слушать не надо

Я правильно понимаю, что на NoSQL смотреть??)

Я правильно понимаю, что на NoSQL смотреть??)

Надо и туда смотреть. Рекомендую взять Berkeley DB любой версии и зафигачить мини интерфейс к ней на любом ЯП (python/perl/c/c++). Сразу войдешь в тему, только дальше надо всеравно изучать SQL и внутренности всех БД. И углубляться. По Oracle DB курсы платные, но стоящие. Впрочем, как и любые курсы :)

Опять же, зачем нужен SQL? Потому что РСУБД решает определенный круг задач. Часто NoSQL базы чтобы решить такие задачи накладывают ряд ограничений, либо вообще не имеют средств (костыляй на клиенте).

Быстро, качественно и недорого, как это не печально.

И сложность растет по экспоненте. Отказ от транзакций ведет к костылям: дублирование данных; риски возникновения критических ошибок из-за того, что забыл проверить другую коллекцию; риск работы с частью данных, т.к. другая операция тупо не сработала и т.д. Все эти вопросы ложатся на плечи разработчиков. Некоторые из них делают форки, вроде TokuMX, прикручивая болтами те самые «модные «ACID с транзакциями»».

Еще скажи, NoSQL это серебрянная пуля. Я готов выслушать аргументы и доводы с реальными вопросами из жизни и железебетонными ответами на них.

какуие СУБД смотреть

Те, по которым самое большее инфы.

Но вообще это неправильный подход. Ты должен чётко определить чем конкретно ты будешь заниматься и уже под эту цель искать и осваивать средства реализации. А то получается, поди туда, не знаю куда, принеси то, не знаю что.

Я правильно понимаю, что на NoSQL смотреть??)

Нет, смотреть на тех кто не в дается в крайности, и использует инструменты под те задачи под которые оне заточены.

Молиться на nosql также херово как и на фичи оракела.

Отказ от транзакций ведет к костылям

Зачем от них отказываться? Если у тебя денормализованная схема и нет связей - то достаточно CAS, да и простая транзакция тут тормозить не будет если запрос адекватен (привет мускуль с блокировками на всю таблицу). В монге например - весь объект == одна запись в коллекции, значит достаточно cas и все.

Это одна сторона.

Если у тебя бюсгалтерия с провотками (привет энтерпрайз) то там без транзакции никуда (и выбрасывать их стам, по меньшей мере странно) - зато это самый распространенный рынок.

Поздняк уже этим заниматься, поезд ушел. Традиционные РСУБД еще везде есть, но уже почти везде легаси. Поддержку активно аутсорсят и переводят в Бангалор. В Мельбурне/Сиднее работу на Оракл уже не найти, ни ДБА, ни девелопером, хотя еще лет 7 назад было валом - народ буквально на куски разрывали. Есть немного спроса на традиционный BI, но BI сейчас стараются переносить на всякие EMR, Redshift и иже с ними - получается дешевле на порядки и в разы эффективней. Мои вложения в Оракл (PL/SQL Developer Professional и Oracle DBA Professional) отбились с лихвой за последние 10 лет, но это время уже ушло и пришлось решительно перепрофилироваться.

В России IT немного запаздывает, плюс на это накладываются нефтебабки, которые бизнес не считает, и им не западло выкинуть миллион-другой на Оракл с саппортом, но нигде в мире такого нет, и в России кризис уже вносит коррективы. Спецсофт навроде WAY4, конечно, останется, но ниша будет очень узкой. Это как сейчас с DB2: оно есть в четырех конторах на всю Москву и по ней есть пара десятков специалистов, которые все друг друга знают в лицо и мигрируют вкруговую по этим четырем работодателям.

Если хочешь быть на острие, то иди в Big Data или в BI. Спрос на эти профессии есть и растет, а специалистов можно по пальцам пересчитать.

По идее в ближайшие год-два спрос на скульщиков должен несколько подняться ибо центробанк закрывает всех подряд и дрюкает отчётностью, так что джуну место найти по идее реально. С перспективами хуже, количество логики на стороне БД постепенно уменьшается.

DB2

Установок полно, но там хранятся только данные ИБМовских софтин типо тиволей, либо дикое легаси

OracleBD

Нас переживёт

SQL Server

Если рассудок и жизнь дороги вам, держитесь подальше от торфяных болот MS SQL Server

Но вообще это неправильный подход

С золотыми словами не спорю :)

Ты должен чётко определить чем конкретно ты будешь заниматься

Сейчас в этом всем моя цель - это вообще переосмыслить теорию; поскольку последний раз я к ней притрагивался оч давно. А так в ближайшее время от меня требуют коллеги по курсу в универе состряпать простую БД, из которой могли брать данные опросов для их впиндюривания в R. Пока что рассматриваю MySQL/MariaDB, поскольку нужна гуи-обертка (LO Base, к примеру) и нужна форма для вставки данных. А гемор весь этот простой: раньше я делал формы для анкетного опроса чеез гугл Формы, но теперь нам (группе) стало понятно, что пора изавбляться от «нинужно» и делать более грамотно. Потом вот, как следующий уровень, я предполагал PostgreSQL, или Оракель или же еще что-то. Но на ранних этапах MySQL...

Oracle Был, есть и будет есть. На больших тырпрайзных проектах и не только. СтОит много и неспроста. Как сказали выше, переживет нас всех.
DB2 - по субъективным ощущениям, какое-то легаси. Хотя лучше промолчу, знаю о нем чуть менее, чем ничего.
Выше говорили, что при изучении PostgreSQL не прогадаешь. И это тоже правда. Оно популярное и в копеечку не вылетает. Для небольших, стильных, модных и молодежных, но не настолько, чтобы nosql, проектах - очень популярна.
SQL Server котируется у .NET-господ, но это только .NET. И пусть его открывают и портируют на все платформы, на нашем веку, сдается мне, ему джаву, а с ней $ANY_OTHER_NON_SQL_SERVER_DB по популярности не превзойти.
Про MySQL и Maria и самому интересно почитать этот тред.

Отказ от транзакций ведет к костылям

Я уже писал выше про банковское/бухгалтерское ПО и прочий биллинг? В остальных случаях оно или не нужно вообще, или реализуется на коленке в два счета.

Еще скажи, NoSQL это серебрянная пуля.

Обязательно скажу, как только оно им станет.

Я правильно понимаю, что на NoSQL смотреть??)

Не совсем. Знать SQL и реляционные СУБД надо, но НЕ возводя их в религию. Та или иная БД — это всего лишь инструмент под задачу. У оракла, бимерских поделок, 1с и прочего добра помимо кажущейся фичастости, псевдоуниверсальности и вымышленной безальтернативности есть опасная особенность — постепенный глубокий вендор-лок. И когда начинается масштабирование в ширину, то поднимается вой.

Посмотри на ЛОР: поиск уже на elasticsearch (а был до этого SOLR). Почему? Потому что SQL СУБД уже прямо сейчас не умееют искать, как не смешно это звучит. А можно на elasticsearch и полностью переехать, он прямо сейчас к этому готов.

Почему-то агрегированные views для olap-ов легче делать в sql сервере, чем в клиенте. И чо-то no-sql от olap-ов далёк... И да, я имею ввиду, что популярные сводные таблицы типа MS OLAP нифига не полезный OLAP для статистика-аналитика, а фуфло для отчётов.

И когда начинается масштабирование в ширину, то поднимается вой.

Вой из-за того, что бабла нет. А не потому, что БД плохая. Вот ты рекомендуешь БД из сферы Big Data, а там тоже платить надо нехило за тех. поддержку. Ну, если в вашей компании не платит, то это не значит, что другие тоже не будут платить и пользоваться на халяву.

НЕ возводя их в религию

Сам же и возводишь. Без обид :)

Вой из-за того, что бабла нет.

О, всё значит деньгами решается? Ждём DBA в треде.

Вот ты рекомендуешь БД из сферы Big Data

Где? Бигдата — это вообще другая плоскость, там часто БД не нужна вообще. Но если нужна, то есть elasticsearch-hadoop для *участия* в обработке бигдаты. Подними на досуге хадуп, напиши пару примеров на cascading, ощути истинные тормоза и потребление ресурсов бигдаты. Но они всё-равно до оракла не дотягивают.

там тоже платить надо нехило за тех. поддержку

Поднять и держать кластер elasticsearch даже школьник сможет, который вчера не осилил SQL как слишком сложный.

Сам же и возводишь. Без обид :)

Просто не видел истинных DBAшников с зашкаливающим уровнем снобизма. А именно они впаривают всем свои говнорешения как будто безальтернативные и создают мифологический информационный фон в мире, что NoSQL == bigdata, хотя это не так.

для статистика-аналитика

elasticsearch + kibana + свои аддоны, которые пишутся html-верстальщиками за еду.

агрегированные views

Я за stateless и линейное горизонтальное масштабирование.

с MariaDB, поскольку, насколько я понял, MySQL хоть и популярен, но фигня

Думаю за две страницы тебе кто-то уже открыл глаза, но всё-же по капитанствую: MariaDB это форк MySQL не так уж сильно отличающийся от исходника. Конечно особенности есть, но в сравнении с любой другой СУБД различий межу MariaDB и MySQL становятся малозаметными.
Вокруг MariaDB в своё время было много хайпа, но хайп это ещё не показатель.

По поводу «фигня-нефигня». На этой фигне (в связке nginx+apapche+php+mysql) работает львиная доля интернета, и вполне нефигово работает. На php жалуются постоянно, а вот на mysql весьма редко (и зачастую не по делу).
На той-же самой фигне работают и многие крупные сайты (например facebook), хотя уж им-то ничего не мешает осилить postgresql или осилить покупку oracledb.
Мускуль беднее в плане тюнинга и фичей чем постгрес или оракал, но тем не менее это вполне годная рабочая лошадка, которую можно с успехом использовать не только на шаред-хостингах.
Реплики снобов в духе «фу, мускуль для быдла» идут туда-же куда и все прочие реплики снобов.

Я имел ввиду социологию, а не веб-«аналитику».
На меня тут заказчик уже обижался, что он дал мне все данные по посетителям сайта, а я говорю, что надо ЦА услуг посчитать.

Я имел ввиду социологию

А в каком плане?))) [просто интересно =)]

Ух ты, как содержательно то!

Спасибось :)))))