Что случилось с сиквельными скиллзами за последние годы?

[Мальчик-Одуванчик]

SQL еще всех нас переживет.
Его практически нечем заменить.

Мощный язык четвертого поколения.

[nightmare2]

... непонятно, почему такие толпы народа считают его непременным атрибутом погромисткой деятельности, да еще считают сиквел и реляционные БД синонимом...

Потому что - это универсальной язык работы с данными.
А данные - это такой зверь, который часто живет не в одном приложении и даже не в двух, и имеет ценность сам по себе.

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

Были еще попытки с объекто-ориентированными БД, но тоже не особо успешно.
Что более-менее прижилось, так это ORM, хотя и тут не все гладко.

[АццкоМото]

Потому что - это универсальной язык работы с данными.
А данные - это такой зверь, который часто живет не в одном приложении и даже не в двух, и имеет ценность сам по себе.

а английский - еще более универсальный, и чо теперь, мы будем пытаться на английском писать дазы банных? не случайно, кстати, в слове SEQUEL первая Е оначает "английский". потому что видение было в 70х, что типа сделай похожий на английский язык запросов и любой бухгалтер сможет строчить любые запросы - и никаких программ не нужно. т.е. это не язык программирования. и он - не для программистов.

совершенный идиотизм, когда в 2016 году пишутся конструкции типа

Code: Select all

// A string that defines the SQL statement for creating a table 
private static final String SQL_CREATE_MAIN = "CREATE TABLE " + 
    "main " +                       // Table's name 
    "(" +                           // The columns in the table 
    " _ID INTEGER PRIMARY KEY, " + 
    " WORD TEXT" 
    " FREQUENCY INTEGER " + 
    " LOCALE TEXT )"; 

И это ГУГЛОВСКИЙ код (http://developer.android.com/guide/topi ... ating.html" onclick="window.open(this.href);return false;), причем существенно упрощенный для примера, в реальности как минимум имена столбцов будут строковыми константами и прочитать этот вымер будет совершенно невозможно не сломав глаза. Хотя казалось бы, что может быть проще.

Хотя, до вас не доходит даже, что само противопоставление SQL и noSQL некорректно. Первое - йызык, а второе - "не реляционный". Ничего не имею против реляционных ДБ в общем случае, но SQL как йызык доступа к ним это долбанный стыд

[stenking]

МонгаДБ - жалкое подобие тех великих предков и ни на что серьезное не годится.
Во всяком случае пока.

Привет послушать так все только и делают что пишут какие-то дикие высоконагруженные системы с петабайтами.

Удивительно только что ездят на цивиках в траффике а не выжимают 200 миль в час на Lamborghini

П.С. Сознаюсь что лузер и никогда выше терабайта не поднимался поэтому мне монги за глаза хватает

[Easbayguy]

МонгаДБ - жалкое подобие тех великих предков и ни на что серьезное не годится.
Во всяком случае пока.

Привет послушать так все только и делают что пишут какие-то дикие высоконагруженные системы с петабайтами.

Удивительно только что ездят на цивиках в траффике а не выжимают 200 миль в час на Lamborghini

П.С. Сознаюсь что лузер и никогда выше терабайта не поднимался поэтому мне монги за глаза хватает

Так у вас и ниша такая, написать прототип/аппликуху на PHP+MySQL/MongoDB/Postgres, база бегает на машинке с 256GB памяти с SSD + какой нибудь распределенный кэш. Данных изначально немного, все летает на ура в памяти. Вполне рабочий вариант. SOX/PCI требований нет.

[blanko27]

... и хрен с ними,с данными. Не очень то надо эти данные. Какая база, такие и данные.

Напомнило комментарий Элона Маска, когда у них последняя ракета при приземлении грохнулась: "По крайней мере куски в этот раз были больше, чем в прошлый раз"

[АццкоМото]

Какая ржака. Один пенсионер предположил идеал своей молодости - самосборный сервер в кладовке и тут же подтянулись другие рубить, крушить и тыкать Стенькинга в какашку. Ага!, а если у тебя сервер выключится, что, не подумал? Вот, какой я умный! Предположить, что на том конце проволоки сидит не дурак - решительно невозможно. Изпацтала практически пишу

[blanko27]

...а если у тебя сервер выключится, что, не подумал? ...

А кому сейчас лего? У кого-то ракеты падают, у кого-то - базы данных. Время сейчас такое: "Waste what's abundant to make up for what's scarce"

[Easbayguy]

A если машина случайоно выключится во время работы МонгоДБ, и данные потеряются, то и хрен с ними,с данными. Не очень то надо эти данные. Какая база, такие и данные.

Вы забыли волшебное слово облако, там они не ломаются, всегда доступны: http://www.crn.com/slide-shows/cloud/30 ... m/pgno/0/1" onclick="window.open(this.href);return false;

[stenking]

A если машина случайоно выключится во время работы МонгоДБ, и данные потеряются, то и хрен с ними,с данными. Не очень то надо эти данные. Какая база, такие и данные.

Вообще-то такие мелочи решаются словом "replication" который в 2016 делается 2-мя кликами а в Google Compute Engine например вообще дефолтом идёт sharding тоже.

[Easbayguy]

A если машина случайоно выключится во время работы МонгоДБ, и данные потеряются, то и хрен с ними,с данными. Не очень то надо эти данные. Какая база, такие и данные.

Вообще-то такие мелочи решаются словом "replication" который в 2016 делается 2-мя кликами а в Google Compute Engine например вообще дефолтом идёт sharding тоже.

Дак все облако и заточено на легкость применения и скорость деплоймента. За это его и любят девелоперы, особенно в небольших компаниях.
Но если нужно больше чем одна база, а их десятки и сотни.
http://configure.us.dell.com/dellstore/ ... =bsd&cs=04" onclick="window.open(this.href);return false;
То даже если брать poweredge R930 v Dell, с 4 CPU (72 core), 192GB pamyati, 3xPCIe SSD, 1.6TB, 4.8TB total, то обойдется всего в 34,000$. У вендоров можно взять дешевле.
Если смотреть: https://aws.amazon.com/rds/pricing/" onclick="window.open(this.href);return false;
db.m4.10xlarge - 1-Year Term, All Upfront $24343 , это не считая других fees.
nо у амазоновской машины будет только 40 vCPU, которая является hyperthreaded core, то есть 20 physical core.
В три раза меньше по вычислительной мощности.

[Likenew]

СЪЛ еще всех нас переживет.
Его практически нечем заменить.

Еще недавно я была того же мнения. Посмотрите на <SparkSQL>. Там надо иметь представление о том, что нужно получить, а потом использовать всякие функции типа <join, aggregate...> КОнечно можно обьявить <data frame> как временную таблицу, тогда можно использовать <SQL> И дело пойдет быстреет, когда сложные запросы, а когда надо выбрать всех людей из департмент=7, то можно И не знать етот <SQL>. Т.е., <SQL> если не исчезнет совсем, то сузит область применеия сильно. Трудно сказать хорошо ето или плохо будет для тхе, кто знает <SQL>, если будет сильная нужда, то могут И платить больше

[nightmare2]

...

Code: Select all

// A string that defines the SQL statement for creating a table 
private static final String SQL_CREATE_MAIN = "CREATE TABLE " + 
    "main " +                       // Table's name 
    "(" +                           // The columns in the table 
    " _ID INTEGER PRIMARY KEY, " + 
    " WORD TEXT" 
    " FREQUENCY INTEGER " + 
    " LOCALE TEXT )"; 

...

Написано коряво, поздравим себя с "разделением труда" , но по сути, чем SQL заменить?
Теоретически можно было использовать какои-нибудь API, например SQL-DMO для SQL Server, но он сцуко для всех БД разный , а SQL стандартизован.
Делай правильный вывод, если даже великие гугло-девелоперы используют SQL, то и нам непозорно.

[Likenew]

Вообще-то дискуссия лишний раз подтверждает тезис диалектического материализма о цикличности развития. Молодые погромисты забыважт, что до SQL было noSQL. Погромисты описывали структуры, использовали исам/всам фаилы для доступа. Потом появились базы и SQL. Сейчас опять возвращаемся к noSQL.

+1

[Likenew]

А если машина случайоно выключится во время работы МонгоДБ, и данные потеряются, то и хрен с ними,с данными. Не очень то надо эти данные. Какая база, такие и данные.

по-любому бацкуп никто в Орацле не отменял тоже.

[mskmel]

Если смотреть: https://aws.amazon.com/rds/pricing/" onclick="window.open(this.href);return false;
db.m4.10xlarge - 1-Year Term, All Upfront $24343 , это не считая других fees.
nо у амазоновской машины будет только 40 vCPU, которая является hyperthreaded core, то есть 20 physical core.

В три раза меньше по вычислительной мощности.

К Деллу надо будет место в стойке (питать, охлаждать, сеть выдать) + суппорт надо платить. Так что там совсем не 34к выходит.
И самое страшное - к Деллу надо будет Easbayguy с его з.п. охренилион в год, а так же кучку подаванов сетевики, бэкап и т.п. Да и долго это всё, пока все CR пройдут, уже продукт и не нужен никому.

В Амазон девелоперы мышкой покликали и всё работает. Никаких тебе злобных DBA, SA, etc, т.е. полная свобода и нирвана. Если поломалось - так это АЖ САМ CLOUD ПОЛОМАЛСЯ. Так что никто не виноват, опа у всех прикрыта.

Edit: главное то и забыл, к одному деллу надо еще такой же в другом DC.

[nightmare2]

...Ничего не имею против реляционных ДБ в общем случае, но SQL как йызык доступа к ним это долбанный стыд

Стыдно не знать SQL, да еще и гордится этим.

[nightmare2]

Привет послушать так все только и делают что пишут какие-то дикие высоконагруженные системы с петабайтами.

Удивительно только что ездят на цивиках в траффике а не выжимают 200 миль в час на Lamborghini

П.С. Сознаюсь что лузер и никогда выше терабайта не поднимался поэтому мне монги за глаза хватает

Размер тут не причем.
МонгиДВ как раз и была созданна для быстой записи и чтения по ключу без излишеств.
Но работа с данным, на этом, как правило, не заканчивается.
Далее придется конвертировать во что-то более подходящее для анализа. Если конечно все эти данные имеют хоть какую-то ценность.

[nightmare2]

Еще недавно я была того же мнения. Посмотрите на <SparkSQL>. Там надо иметь представление о том, что нужно получить, а потом использовать всякие функции типа <join, aggregate...> КОнечно можно обьявить <data frame> как временную таблицу, тогда можно использовать <SQL> И дело пойдет быстреет, когда сложные запросы, а когда надо выбрать всех людей из департмент=7, то можно И не знать етот <SQL>. Т.е., <SQL> если не исчезнет совсем, то сузит область применеия сильно. Трудно сказать хорошо ето или плохо будет для тхе, кто знает <SQL>, если будет сильная нужда, то могут И платить больше

Посмотрел одним глазом.
Напоминает Entity Framework (LINQ to Entity).
Т.е. очередной ORM.
Кстати, существуют у другие интерфейсы к реляционным БД, например OData.
SQL никуда не делся и если что-то пойдет не так, придется его читать в профайлере или другом подобном инструменте.
Я не говорю, что ORM - это плохо, наоборот, мне эта штука очень нравится, но sql по-прежнему надо знать.

SQL исчезнет только если будет предложена успешная новая, лучшая, концепция БД.
Теоретически, развитие NoSQL может к этому привести, когда-нибудь, но пока у мен я нет никаких оснований верить в это.

[nightmare2]

А если машина случайоно выключится во время работы МонгоДБ, и данные потеряются, то и хрен с ними,с данными. Не очень то надо эти данные. Какая база, такие и данные.

по-любому бацкуп никто в Орацле не отменял тоже.

Дело не бэкап, у МонгиДВ нет транзакций (во всяком случае не было раньше), поэтому невозможно откатить повреждения, если что.
Т.е. если она упадет, то какие-то данные будут действительно потеряны.
Это далеко не всегда приемлемо.

[stenking]

МонгиДВ как раз и была созданна для быстой записи и чтения по ключу без излишеств.
Но работа с данным, на этом, как правило, не заканчивается.
Далее придется конвертировать во что-то более подходящее для анализа. Если конечно все эти данные имеют хоть какую-то ценность.

Там lookup добавили - эквивалент join, но тут скорее просто разные подходы к дизайну баз. Одни нормализированные, другие денормализированные. И там и там свои плюси и минусы.

[stenking]

Дело не бэкап, у МонгиДВ нет транзакций (во всяком случае не было раньше), поэтому невозможно откатить повреждения, если что.
Т.е. если она упадет, то какие-то данные будут действительно потеряны.
Это далеко не всегда приемлемо.

Есть, только чуть с большим синтаксом и "ручной" работой.

[valchkou]

МонгиДВ как раз и была созданна для быстой записи и чтения по ключу без излишеств.
Но работа с данным, на этом, как правило, не заканчивается.
Далее придется конвертировать во что-то более подходящее для анализа. Если конечно все эти данные имеют хоть какую-то ценность.

Там lookup добавили - эквивалент join, но тут скорее просто разные подходы к дизайну баз. Одни нормализированные, другие денормализированные. И там и там свои плюси и минусы.

Там еще много чего добавили, теже aggregate/ аналог group by, т.е если раскарячиться то на монге можно делать запросы почти аналогичные SQL. Проблема монги в том что они придумали свой кривой способ, вместо использования всем понятного SQL.
Но общественность не дремлет, думаю что очень скоро родится полноценная SQL обертка к монге

Другое дело кассандра, за основу взяли SQL, он без join и grouping.
Но в связке со Spark/Solr позволяет рассправить плечи любому динозавру SQL.

короче говоря SQL продолжает набирать обороты, и как ни странно благодаря NoSQL и бигдата.

[nightmare2]

...Там lookup добавили - эквивалент join, но тут скорее просто разные подходы к дизайну баз. Одни нормализированные, другие денормализированные. И там и там свои плюси и минусы.

С этим спорить не буду.
Я лишь хотел сказать, что NoSQL не заменяет релаиционные БД.
Самое разумное было бы добавить NoSQL возможности в существующие реляционные БД.
Собственно SQL Server 2016 уже будет работать с JSON.

[nightmare2]

Дело не бэкап, у МонгиДВ нет транзакций (во всяком случае не было раньше), поэтому невозможно откатить повреждения, если что.
Т.е. если она упадет, то какие-то данные будут действительно потеряны.
Это далеко не всегда приемлемо.

Есть, только чуть с большим синтаксом и "ручной" работой.

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