Это копия, сохраненная 18 октября 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Юзал Sequelize в десятке проектов, лютейшая годнота. Для SQL баз ничего лучше нет. Для монго - Mongoose. Ещё слышал о Bookshelf, но не юзал.
Бэкапы, откаты из бэкапов, откаты из дейли лога insert/update запросов, ручные вмешательства в БД самые разные, мониторинг производительности, тюнинг конфигов, выдача пиздюлей программистам в ряде случаев, переход на новую версию СУБД, иногда решение архитектурных вопросов совместно со всякими там архитекторами и погромистами. Зачастую работа со всем этим в контексте многосерверного кластера.
за графовые базы кто пояснит? бэкапы, репликация, подводные камни.
- Синхронная как минимум, асинхронная как плюс.
- Транзакционная.
- Чтоб можно было быстро апдейтить поле у одного документа.
- Апдейт полей у нескольких документов по айдишникам.
- Апдейт полей у документов попадающих под кверю.
- Возможность хранить BLOB-ы.
- Кластеризаци/распределенность ибо документов будет не мало (от сотен тысяч до нескольких миллионов).
Сейчас юзаю Постгрес + Эластик.
Какие предложения? У Постгреса, вроде как, есть возможность хранить нереляционные данные, но я никогда не имел с этим дела.
Пик анрелейтед.
Поясните за Cassandra. В чём отличия от обычных SQL баз?
В постгресе есть JSON тип и операторы к нему, но не факт, что твоя ORM реализует полную обертку к этим операторам, а это может стать причиной лютого говнокода. Хотя sqlalchemy, например, поддерживает более-менее json. А вот бенчмарк выборок: http://blog.2ndquadrant.com/jsonb-type-performance-postgresql-9-4/
В случае если документы являются основой проекта, код моделей будет легче поддерживать, если используешь mongodb, так как обертки к ней более явные.
Эта вообще nosql база, там конечно есть язык запросов, но агрегаций и джойнов в нем нет. Используется в случаях, когда нужна быстрая запись, а быстрые и сложные выборки не нужны, пример такой ситуации сбор статистики или web-crawling.
Например:
8:13:55 + 10:0:5 + 20:0:0 = 38:14:0
Как мне хранить именно в таком формате (1244:40:43)?
Какой тип данных выбрать?
Ставь линупс и не еби мозги
dba не нужен.
Не еби себе мозг.
поставь буткамп, затем нормальный виндовоз, сверху оракл и остальное чо хочешь.
sql develepor выбрось нахуй и поставь toad.
если хочешь таки ебаться с виртуалками, скачай с оракл.сом виртуальный
эпплаянс с уже установленным ораклом, это редхат на самом деле.
макось охуенная вещь для дизайнеров и иос-дрочинга, но не дб-дев.
телнетом в порт виртуалки удаётся достучаться?
MySQL, таблицы с типом "MEMORY".
В общем я нихуя не программист, я блядский инженер, да даже сейчас и не инженер, а техник. В общем занимаюсь востановлением и мелкой проектировкой электроники. Но не суть.
Есть пара вопросов:
Что нужно знать Что бы быть админом oracle sql?
С чего вообще начинать изучение? Готов курить литературу на английском. Если тут есть админы то прошу захуячти мне фак. Я очень прошу, вы мне так сильно поможите. Умоляю антоши.
буду бампать свой вопрос пока не заебу вас.
Вверх ребята, вверх.
В мускуль 57 тоже json завезли, даже амахон поддерживает.
как вам sqlite3?
если да, то как выполнятор запроса узнает, нужно ли обращаться к индексу для поиска данных, либо перебирать все существующие строки (в случае кучи)? это все хранится в метаданных (мб неправильный термин) таблиц или вью, или что-то вроде внутренней реализации if exists (select superindex from sys_objects)?
не DBA
бамп, или хотя бы подскажите литературу по MSSQL годную (для уровня быдлокодер), где этот вопрос можно осветить для себя
Когда я создаю курсор с селектом без лимита на большую базу, данные как-то кешируются или курсор сразу все в себе имеет? Sqlite.
Случайно реплай.
даже на википедии написали, а ты найти не можешь
Cursors allocate resources on the server, such as locks, packages, processes, and temporary storage. For example, Microsoft SQL Server implements cursors by creating a temporary table and populating it with the query's result set. If a cursor is not properly closed (deallocated), the resources will not be freed until the SQL session (connection) itself is closed. This wasting of resources on the server can lead to performance degradations and failures.
> For example, Microsoft SQL Server implements cursors by creating a temporary table and populating it with the query's result set.
Sqlite. И что если там база большая, на полный селект он ее всю во временную скопирует?
такое пишут
http://stackoverflow.com/questions/10376691/how-does-a-sqlite-cursor-work-internally
на самом деле, не логично при каждом проходе энумеровать запрос заново, даже если не строить каждый раз план выполнения
В бд есть две таблички:
1. Customer
Id|Name
------------------
1|Ivanov
2|Petrov
3|Sidorov
2. CustomerInfo
Id|Field |Value
----------------------------------------
1|FirstName|Ivan
1|Phone|123456789
2|FirstName|Peter
2|Phone|987654321
3|FirstName|Sidor
Таблички связаны по полю Id
Требуется написать SQL-запрос, возвращающий следующий резултат
ID|FirstName|Name|Phone
-----------------------------------------------
1|Ivan |Ivanov|123456789
2|Peter|Petrov|987654321
3|Sidor|Sidorov |
В бд есть две таблички:
1. Customer
Id|Name
------------------
1|Ivanov
2|Petrov
3|Sidorov
2. CustomerInfo
Id|Field |Value
----------------------------------------
1|FirstName|Ivan
1|Phone|123456789
2|FirstName|Peter
2|Phone|987654321
3|FirstName|Sidor
Таблички связаны по полю Id
Требуется написать SQL-запрос, возвращающий следующий резултат
ID|FirstName|Name|Phone
-----------------------------------------------
1|Ivan |Ivanov|123456789
2|Peter|Petrov|987654321
3|Sidor|Sidorov |
или pivot? ну короче, одно из двух
Безусловно.
Чувак, я нихера не понял что ты сказал, но ты достучался до моего сердца.
https://www.citusdata.com/blog/1872-joe-nelson/409-five-ways-paginate-postgres-basic-exotic
https://habrahabr.ru/post/301044/
так он же не о пагинации вопрошал. насколько я понял, товарищу был важен знать механизм, как система отберет записи, находящиеся в ебенях таблицы, если план выполнения точно знает, что выбирать нужно именно их.
чи не?
Допустим, у тебя индекс по полю ID. Если твой SELECT ищет по полю ID, то для поиска записей будет использован этот индекс. Если же использовалось дополнительно ещё какое-то поле, то будет произведен поиск среди записей, которые были найдены по индексу.
Насчет "загрузятся" - нет, не совсем. Сервер найдет записи, но не будет их загружать. Индекс, однако, может содержать определенные поля. То есть индекс по ID может дополнительно содержать копию данных из поля Login, и тогда SELECT [Login] FROM [Table] WHERE ID IN (1,2,5) вернёт тебе нужную информацию даже не читая конкретные записи, а прямо из индекса.
Я читал вот эту статью
http://use-the-index-luke.com/no-offset
>offset instructs the databases skip the first N results of a query. However, the database must still fetch these rows from the disk and bring them in order before it can send the following ones.
WTF?
Кстати я в целом разделяю его аргументы, особенно про пагинацию на меняющихся данных, когда постоянно все куда то убегает - это просто пиздец. Но допустим что таблица у меня неизменна и я реально хочу выбрать с 1000000 по 1000010 элемент. Меня интересует вопрос на сколько это (не)эффективно.
Проиграл с колдунств в обсуждении статьи на хабре. Вся суть свитеропетушения. Самое дно разработки, хуже верстки.
По моим представлениям, чтобы прыгнуть сразу в нужное место дерево индекса должно хранить дополнительную информацию о размере поддеревьев. Почему ни один из вендоров не додумался до этого "уникального" юзкейса - это просто у меня в голове не укладывается. Надеюсь, что я просто ошибаюсь, но, я повторюсь, судя по всему дна хуже свитеропетушения просто нет.
В общем есть база данных в ней записи с колонками "дата" "время" и "имя пользователя". Известно четыре имени пользователя, которых условно можно отнести к группе "местные ребята", а все остальные имена соответственно к группе "не местные ребята".
Вопрос вот в чем: как сделать выборку по датам таким образом, что бы сгруппировав все записи по датам, поставить статус напротив каждой группы "встретились только местные" / "встретились не только местные" / "встретились только не местные".
Я не студент, интересуюсь для общего развития т.к. хочу уже свои скрипты научить данные в базу выгружать, а не по текстовым файлам хранить как лох.
Ниже код, выборки и задачи писал себе сам, я застрял на этапе "-- when players can't make full party and is it regular party or not?" с полной-неполной группой получилось разобраться, а вот определить статус группы нет:
/ Friendly Card Game Results:
During this past winter, a few friends got together every Wednesday night for a friendly game of cards. On some nights they'd play two games, but never the same game twice on the same night. The usual players were Spunky Sam, Marcimus, Winston, and Hopper. Sometimes, one of the friends couldn't make it, so there were only three players. But sometimes they'd call another friend to fill-in. In every game they played, the one with the hightest score was declared the winner. These are their results:
Created by: https://www.khanacademy.org/profile/brianduckworth
/
CREATE TABLE card_games(id INTEGER PRIMARY KEY AUTOINCREMENT,
date_played TEXT,
game_name TEXT,
player_name TEXT,
score INTEGER);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/07','Rummy','Spunky Sam',226);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/07','Rummy','Marcimus',418);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/07','Rummy','Winston',523);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/07','Rummy','Hopper',311);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Go Fish','Spunky Sam',7);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Go Fish','Marcimus',5);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Go Fish','Winston',4);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Go Fish','Hopper',10);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Crazy Eights','Spunky Sam',215);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Crazy Eights','Marcimus',167);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Crazy Eights','Winston',109);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Crazy Eights','Hopper',192);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/21','Rummy','Spunky Sam',473);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/21','Rummy','Marcimus',324);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/21','Rummy','Hopper',516);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/28','Crazy Eights','Spunky Sam',119);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/28','Crazy Eights','Marcimus',212);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/28','Crazy Eights','Purple Pi',314);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/28','Crazy Eights','Hopper',252);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Go Fish','Spunky Sam',3);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Go Fish','Marcimus',11);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Go Fish','Winston',12);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Go Fish','Hopper',0);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Pitch','Spunky Sam',17);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Pitch','Marcimus',22);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Pitch','Winston',-3);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Pitch','Hopper',9);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/11','Rummy','Amelia',525);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/11','Rummy','Marcimus',419);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/11','Rummy','Winston',316);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/11','Rummy','Hopper',398);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/18','Crazy Eights','Spunky Sam',119);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/18','Crazy Eights','Marcimus',231);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/18','Crazy Eights','Winston',153);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/18','Crazy Eights','Hopper',175);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Pitch','Spunky Sam',12);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Pitch','Marcimus',6);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Pitch','Winston',21);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Go Fish','Spunky Sam',6);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Go Fish','Marcimus',7);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Go Fish','Winston',13);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/04','Rummy','Spunky Sam',378);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/04','Rummy','Marcimus',327);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/04','Rummy','Winston',413);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/04','Rummy','Hopper',517);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/11','Pitch','Spunky Sam',-1);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/11','Pitch','Marcimus',-5);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/11','Pitch','Winston',7);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/11','Pitch','Hopper',22);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/18','Crazy Eights','Spunky Sam',91);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/18','Crazy Eights','Marcimus',153);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/18','Crazy Eights','Amelia',174);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/18','Crazy Eights','Mr. Pink',216);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/25','Rummy','Spunky Sam',416);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/25','Rummy','Marcimus',505);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/25','Rummy','Winston',397);
SELECT FROM card_games;
/
What are average, max, and min values in the data?
id (PK) INTEGER
date_played TEXT - total / per day
game_name TEXT - most popular / least popular
player_name TEXT - players per match / total most and least popular player
score INTEGER - per game / average
*/
--get player names
select player_name as 'player names' from card_games group by player_name;
-- determine and separate usual and unusual players
select player_name,
case
when player_name in ("Spunky Sam","Marcimus","Winston","Hopper")
then "Usual player"
else "Unusual player"
end as player_status
from card_games
group by player_name
order by player_status;
-- when players can't make full party and is it regular party or not?
select
game_name as game
,date_played as date
,count(player_name) as players
,case
when count(player_name) < 4 then "Not full party"
else "Full party"
end as "meeting status"
-- problem below - how to determine party status?
,case
when player_name in
("Amelia","Mr. Pink","Purple Pi")
then "Not regular party"
else "Regular party"
end as "party status"
from
card_games
group by
date_played
,game_name
order by
date_played;
-- how many times they call unusual player?
В общем есть база данных в ней записи с колонками "дата" "время" и "имя пользователя". Известно четыре имени пользователя, которых условно можно отнести к группе "местные ребята", а все остальные имена соответственно к группе "не местные ребята".
Вопрос вот в чем: как сделать выборку по датам таким образом, что бы сгруппировав все записи по датам, поставить статус напротив каждой группы "встретились только местные" / "встретились не только местные" / "встретились только не местные".
Я не студент, интересуюсь для общего развития т.к. хочу уже свои скрипты научить данные в базу выгружать, а не по текстовым файлам хранить как лох.
Ниже код, выборки и задачи писал себе сам, я застрял на этапе "-- when players can't make full party and is it regular party or not?" с полной-неполной группой получилось разобраться, а вот определить статус группы нет:
/ Friendly Card Game Results:
During this past winter, a few friends got together every Wednesday night for a friendly game of cards. On some nights they'd play two games, but never the same game twice on the same night. The usual players were Spunky Sam, Marcimus, Winston, and Hopper. Sometimes, one of the friends couldn't make it, so there were only three players. But sometimes they'd call another friend to fill-in. In every game they played, the one with the hightest score was declared the winner. These are their results:
Created by: https://www.khanacademy.org/profile/brianduckworth
/
CREATE TABLE card_games(id INTEGER PRIMARY KEY AUTOINCREMENT,
date_played TEXT,
game_name TEXT,
player_name TEXT,
score INTEGER);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/07','Rummy','Spunky Sam',226);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/07','Rummy','Marcimus',418);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/07','Rummy','Winston',523);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/07','Rummy','Hopper',311);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Go Fish','Spunky Sam',7);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Go Fish','Marcimus',5);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Go Fish','Winston',4);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Go Fish','Hopper',10);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Crazy Eights','Spunky Sam',215);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Crazy Eights','Marcimus',167);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Crazy Eights','Winston',109);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/14','Crazy Eights','Hopper',192);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/21','Rummy','Spunky Sam',473);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/21','Rummy','Marcimus',324);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/21','Rummy','Hopper',516);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/28','Crazy Eights','Spunky Sam',119);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/28','Crazy Eights','Marcimus',212);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/28','Crazy Eights','Purple Pi',314);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/01/28','Crazy Eights','Hopper',252);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Go Fish','Spunky Sam',3);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Go Fish','Marcimus',11);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Go Fish','Winston',12);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Go Fish','Hopper',0);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Pitch','Spunky Sam',17);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Pitch','Marcimus',22);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Pitch','Winston',-3);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/04','Pitch','Hopper',9);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/11','Rummy','Amelia',525);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/11','Rummy','Marcimus',419);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/11','Rummy','Winston',316);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/11','Rummy','Hopper',398);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/18','Crazy Eights','Spunky Sam',119);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/18','Crazy Eights','Marcimus',231);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/18','Crazy Eights','Winston',153);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/18','Crazy Eights','Hopper',175);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Pitch','Spunky Sam',12);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Pitch','Marcimus',6);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Pitch','Winston',21);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Go Fish','Spunky Sam',6);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Go Fish','Marcimus',7);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/02/25','Go Fish','Winston',13);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/04','Rummy','Spunky Sam',378);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/04','Rummy','Marcimus',327);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/04','Rummy','Winston',413);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/04','Rummy','Hopper',517);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/11','Pitch','Spunky Sam',-1);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/11','Pitch','Marcimus',-5);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/11','Pitch','Winston',7);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/11','Pitch','Hopper',22);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/18','Crazy Eights','Spunky Sam',91);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/18','Crazy Eights','Marcimus',153);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/18','Crazy Eights','Amelia',174);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/18','Crazy Eights','Mr. Pink',216);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/25','Rummy','Spunky Sam',416);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/25','Rummy','Marcimus',505);
INSERT INTO card_games(date_played,game_name,player_name,score) VALUES ('2015/03/25','Rummy','Winston',397);
SELECT FROM card_games;
/
What are average, max, and min values in the data?
id (PK) INTEGER
date_played TEXT - total / per day
game_name TEXT - most popular / least popular
player_name TEXT - players per match / total most and least popular player
score INTEGER - per game / average
*/
--get player names
select player_name as 'player names' from card_games group by player_name;
-- determine and separate usual and unusual players
select player_name,
case
when player_name in ("Spunky Sam","Marcimus","Winston","Hopper")
then "Usual player"
else "Unusual player"
end as player_status
from card_games
group by player_name
order by player_status;
-- when players can't make full party and is it regular party or not?
select
game_name as game
,date_played as date
,count(player_name) as players
,case
when count(player_name) < 4 then "Not full party"
else "Full party"
end as "meeting status"
-- problem below - how to determine party status?
,case
when player_name in
("Amelia","Mr. Pink","Purple Pi")
then "Not regular party"
else "Regular party"
end as "party status"
from
card_games
group by
date_played
,game_name
order by
date_played;
-- how many times they call unusual player?
тебе инсерты надо было обязательно включать, сучара?
я бы создал темптейбл с айдишниками правильных пацанят. далее общую выборку лефтджойнишь на временную таблицу: если нет записей с null - все свои, если все нулл - все левые, иначе - салат с мелкопорубленными огурцами
Засунь это в sqlfiddle, не надо такие простыни пастить
> Мне удалось построить свою маленькую Exadata в Amazon cloud. Теперь этот проект называется Engineered System at home in cloud. Вы знаете, что даже у Oracle нет Engineered System in cloud? А у вас - будет. Как только я осилю оформление инструкции -)
> Стоимость построения - примерно $15. Эксплуатации - зависит от продолжительности.
> Прелесть по сравнению c решением на домашней виртуальной машине - у вас есть возможность получить много ресурсов. Немедленно. И заплатить за них смешные деньги. Посмотрите какие типы виртуальных машин можно получить. 32 vcpu, 244 Gb памяти.
> Она из самых замечательных возможностей - то что можно произвести настройку системы на одном типе инстанса (что дешевле), а потом изменить тип инстанса - получить много памяти и процессоров на короткое время теста - потом вернуть обратно.
> Можно долго бубнить о том как же сравнить текущую систему с тем что там в Amazon, что там vcpu - а можно сделать baseline test, дальше включить InMemory, дальше подключить Exadata Cell. Со своего ноутбука - вам не понадобиться ничего, кроме ssh и браузера. В Новосибирске, Красноярске или даже в Омске можно за выходные узнать о том, как работают все новомодные опции Oracle за, как мне кажется, разумные деньги
> http://dsvolk.blogspot.ru/2014/11/engineered-system-at-home-breaking-news.html
> postgresql 9.6 beta2
update most contrib extensions for parallel query
two fixes for pg_trgm (trigram) bugs
rewrite code to estimate join sizes for better performance
correct handling of argument and result datatypes for partial aggregation
fix lazy_scan_heap so that it won't mark pages all-frozen too soon
mark additional functions as parallel-unsafe
check PlaceHolderVars before pushing down a join in postgres_fdw
improve the situation for parallel query versus temp relations
don't generate parallel paths for rels with parallel-restricted outputs
make psql_crosstab plans more stable
finish loose ends for SQL ACCESS METHOD objects, including pg_dump
stop the executor if no more tuples can be sent from worker to leader
several pg_upgrade fixes to support new features
fix regression tests for phrase search
add new snapshot fields to serialize/deserialize functions
measure Bloom index signature-length reloption in bits, not words
many improvements to parallel regression tests
many documentation updates and clarifications
multiple translation updates for the docs
Например, в 10g движок хавал селекты с /r/n в качестве перевода строки, но не хавал аналочиные апдейты. Т.е. селект и апдейт там парсился разным былокодом. Учитывая, что это говно написано на С/C++ я не удивлюсь, если там вообще используются разные библиотеки для работы со строками.
В общем да, если сравнивать СУБД с языками программирования, Оракли == С++.
Стал популярным случайно - Ларри спиздил недоделанные исходники из IBM-а и стал загонять их аж как вторую версию своей чудо-СУБД, а быдло поверило; за счет чего держится - не понятно, т.к. не обладает никакими преимуществами по сравнению с конкурентами и чуть ли не самый медленный; все от него плюются и только узкий круг ограниченных ораклисвиней, которые ничего кроме оракли не знают и не видели, кормятся опилками с распилов от неудачных внедрений и считают себя сука илитой.
И да, каждый ламерок, чинушка или олокомпьютерный свитер жаждет засунуть оракли куда только его волосатые рученки дотянутся, потому что где-то слышал, что оракли это круто. Где они все это слышат, я не знаю, как-то пора выжечь это место, чтобы зараза не распространялась.
INTERVAL
sql server вырвиглазный платформлок
informix мертв
db2 не нужон
freesoft - не имеет встроенных менеджеров очередей, готовых dbms_what_you_want и повышает шанс замены студента админа с кучей сертификатов школьником, умеющим ставить lamp. Ах да, специалистов нема.
Что там ещё?
SQLite бери.
Рассказываю.
Чтобы что-то update или delete, это что-то нужно сначала найти. Если существует индекс, совместимый с условиями поиска, он будет использован. Если нет, будет full scan (полный перебор всей таблицы).
Если в результате изменения таблицы изменятся поля, учааствующие в индексе, то в индекс будут внесены изменения, соответствующие изменениям в таблице.
при удалении записи изменения в структуре индекса произойдут гарантированно, nyet?
но, в любом случае, ты хочешь мне сказать, что издержки, связанные с перестроением индекса хотя бы в трети случаев соизмеримы с прибавкой скорости поиска записей?
конечно
Не путай изменение индекса с перестройкой индекса.
>>783669
Умница, ты ведь сам все знаешь.
Если у тебя таблица на 10 записей, то в индексах нет никакого смысла, разумеется.
Если у тебя таблица на 10 миллиардов записей, то издержки связанные с поддержанием индекса в актуальном состоянии будут незаметны на фоне увеличения скорости поиска.
Если ты не понял предельно точный вопрос, значит, ты слишком туп, чтобы на него ответить.
Я понял даже твоё несвязное бормотание.
Это не означает что учиться излагать мысли связно на родном языке тебе не нужно.
Поясните мне следующие вопросы. Постараюсь изложить максимально внятно:
1. Нормально ли когда в документо-ориентированных базах мы в документ запихиваем максимум информации и в каждом документе дублируем одно по одному, вместо того чтоб сделать ссылку. Например, если у нас база товаров, и каждый товар описывается документом, то мы в каждый документ записывам всю инфу о прозиводителе типа там "Самсунг, корея, доллары", а не делаем ссылку на коллекцию с производителями.
2. Если нужен отклик 0,1-0,5 секунд для базы в миллион документов, каждый из которых содержт списки и весит по 100-200кб, справится ли MongoDB с таким? или же уже стоит смотреть в сторону изменения модели данных и использования key-value баз? Понятно что зависит от многих других факторов, но хотелось бы примерно узнать.
3. в реляционных базах можно делать вложенные запросы, типа SELECT ... from ... (SELECT ...),Можно ли подобное делать в документных, типа сделали выборку документов, потом из этой выборки делаем другую выборку и тд. И сразу вопрос про key-value, что там с операцией пересечения множеств? K1 -> S1, K2 -> S2 ... И вот я делаю выборку по этим ключам, но нужно пересечение S1 с S2 и т.д.
Задавай свои вопросы.>>785434
>Нормально ли когда в документо-ориентированных базах
Нормально для документо-ориентированных недоБД.
Дело в том что в них буква C из аббревиатуры ACID означает только атомарность изменений на уровне одного объекта. Поэтому как только ты сделаешь куда-то линк, поддерживать его ты не сможешь и не сможешь поддерживать консистентность твоей базы данных. Поэтому кроме такого варианта - лепить все в один документ - вариантов просто нет.
Есть нереляционные БД с нормальной (и даже очень хорошей поддержкой транзакций и ACID, а не карикатуры на него), но для работы с ними тебе потребуется купить мейнфрейм. Кстати, они - вместе с качественно реализованными транзакциями и ACID - были задолго до реляционных - поинтересуйся в какой версии Oracle вообще транзакции появились.
> Если нужен отклик 0,1-0,5 секунд для базы в миллион документов
С этим справится PostgreSQL без проблем. Даже с дефолтными настройками, которые ему достались в память о тех временах когда 256 мегабайт RAM были непозволительной роскошью.
> справится ли MongoDB с таким?
Справится. Но будь готов к тому найдется ли твой документ или нет будет зависеть от фазы Луны - https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.s3ko3vfnx
Исходя из твоего ответа, верноли я понял что всякие монги это всё хипстерская тема, которая работает нестабильно и жрет много памяти. И что лучше постараться обойтись традиционными реляционными средствами.
{id: N, data: [[25,10,1,52],[4,25],[10,52,81]]}
data - это список списков, каждый список может быть длиной от 1 до 1000, и самих этих списков может быть 1-100, но как правило всё в пределах 10-20. Вместо чисел строки.
Таких вот блоков может быть миллион и более. Запись производится редко, и ее скорость вообще неважна. А вот чтение нужно быстрое, запрос примерно выглядит так: дан набор чисел, например 25,4,52. Нужно выдать все id, для которых соответствующая data содежит эти числа. И нужны хорошие средства для сортировки результата, чтоб можно было писать свои нетривиальные функции (критерии) сортировки.
Изменится ли как-то задача, если data - это будет дерево.
>в чем смысл key-value
хуяк-хуяк, не надо ничего знать, кидай щебень лопатой в монгу, хуяк-хуяк
Есть sql код, создающий бд. Какой нужен инструмент, программа, чтобы записать с помощью этого кода данные в excel?
Из-за такой хуйни сервер поднимать? Может онлайн инструмент есть?
Еще есть текстовик с выгруженой базой, есть программка для простого парсинга?
тебе в жс-тред
Бдует полезно тем кто не знает SQL и не работал с РСУБД
PostgreSQL, Oracle, SQLite и MS SQL Server он поддерживает кроме MySQL.
http://sqlfiddle.com
Менюшечка сверху слева.
Люди, умеющие использовать временные таблицы, за каким хером вообще пойдут на этот fiddle?
Все это для нубов, разумеется.
дабы показать пример работающего кода воочию
ну, и для того случая, когда СУБД под рукой может не быть
Кстати, а есть же наверное у MS какие-то бесплатные аккаунты в Azure с MS SQL Server для популяризации его среди трудящихся?
месяц триала. в данный момент, насколько я знаю, требуют при регистрации номер кредитки
Вообще 10гигов база это что-то крупное уже или детский лепет?
Очевидный MongoDB in action.
Какой-то мануал, на русском с детальным объяснением как с этой штукой обращаться.
Нужна встраиваемая графовая база данных. Приоритет - производительность, многопоточность. Будет работать только на одной машине.
Одной-двумя записями манипулируй где хочешь. Если запрос с парой джоинов, группировкой и сортировкой - пусть это сделает бд.
> RDF triple store
> When you download the free version of AllegroGraph, no License Key is provided or required. The free version lets you load a maximum of 5,000,000 triples, and has no expiration date.
Толсто
>при удалении записи изменения в структуре индекса произойдут гарантированно, nyet?
Все зависит от того с какой СУБД ты работаешь. Ее надо знать.
Например, в PostgreSQL при удалении записи индекс никто даже с диска поднимать не будет, он не изменится. В самой таблице запись будет помечена флажком "удаленная".
В чем твой вопрос, долбоеб?
Ты хотел высокопроизводительную графовую СУБД, пригодную для встраивания? Ты ее получил.
> http://techblog.netflix.com/2016/06/netflix-billing-migration-to-aws.html
> The truth is, moving to the cloud was a lot of hard work, and we had to make a number of difficult choices along the way. Arguably, the easiest way to move to the cloud is to forklift all of the systems, unchanged, out of the data center and drop them in AWS. But in doing so, you end up moving all the problems and limitations of the data center along with it. Instead, we chose the cloud-native approach, rebuilding virtually all of our technology and fundamentally changing the way we operate the company.
Всё переписали, убили тучу времени и денег, в процессе нахреначили новых багов взамен исправленных старых.
Вот нахуя?
Напиши.
Что не так? Уменьшили технический долг, которого всегда очень много в энтерпрайзе. Через год стабилизируют код и будет заебись.
https://www.reddit.com/r/programming/comments/4rc9uu/say_no_to_venn_diagrams_when_explaining_joins/
https://blog.jooq.org/2016/07/05/say-no-to-venn-diagrams-when-explaining-joins/
А я то думал когда мельком на эту хуету натыкался - ну чего несут, просто охуительные истории какие-то. Но лень было особо разбираться. А оказывается так и есть, свитера все-таки ебанутейший народец.
Любой кто считает что
1. Всю бизнес логику следует хранить в базе
2. SQL хороший язык программирования
Понятно, все кто не говнОРМщики и знают про что-то чуть большее чем "селект звездочка".
А почему именно слово "свитер"?
Это уже давно устоявшийся мемец, так что луркай нубяра.
Алсо знал двух таких долбоебов и их любимая одеждой-униформой был ну-ты-понел. Совпадение? Не думаю.
Я в замешательстве. Свитера тоже иногда ношу, английские, из тонкого кашемира.
Как же теперь быть.
Мне показалось что тебе пытались намекнуть что кичться собственным незнанием чего-то и неумением чего-то - как минимум, неумно.
Отнимает работу у говнОРМщиков.
Ставишь PostgREST и оказывается что в 98% случаев их говноконвертор селектов в JSON, на каком-нибудь тормозном уебище типа рельсов, НИНУЖЕН вообще, от слова "совсем".
select
Customer.id as ID,
fname.value as FirstName,
Customer.name as Name,
phone.value as Phone
from Customer
inner join CustomerInfo fname on customer.id=fname.id and fname.field='FirstName'
inner join CustomerInfo phone on customer.id=phone.id and fname.field='Phone'
а воще за такой дезигн таблиц нада убивать
делаю
select id, word from words where id > 900000 and id < 1000000;
запрос 0.43 секунды выполняется. Это очень долго. Нужно в сотни раз быстрее.
Но если 900000 заменить на 990000 - то быстрее в 10 раз. То есть дело видимо в физическом считывании. В общем что делать? Индекс какой-то использовать или что? Хотя я проиндексировал столбцы.
Из 0.43 секунд 0.4299 секунд ты данные фетчишь.
Фетчи быстрее, выкинь Ruby.
И explain (analyze, buffers) в студию.
Что ты собрался делать сразу с сотней тысяч записей?
https://www.postgresql.org/docs/9.3/static/sql-fetch.html
>А что в этом плохого?
Держать бизнес-логику в базе - это как кодить на брейнфаке палочкой торчащей из ануса. Но свитерам нравится.
Да хоть из OCaml, кто знает насколько эффективно твой Rust работает с БД на уровне протокола и через какую рукожопию у него десериализация.
Еще раз - explain (analyze, buffers) в студию, телепаты в отпуске.
> там дальше с этими 100 000 записями должны быть еще действия
Вот и делай их последовательно, эти действия, зачем тебе сразу 100000 записей выгребать-то, и быстро? Лучше всего прямо рядом с данными и делай, и выгребай уже готовые результаты - всё лучше чем циклами в совем Rustе по ним же и бегать. Напиши на своей расте обработку данных, возьми курсор, и обрабатывай сколько надо - https://github.com/thehydroimpulse/postgres-extension.rs
>Держать бизнес-логику в базе - это как
Конечно, лучше вложенными циклами по "селект звездочка вхере id = i" пердолиться как в 1989 году с пачкой dbf-файлов. Рассказывать потом еще как СУБД "тормозит".
К тому же вся твоя "бизнес-логика" обычно это взять "селект звездочку" и в JSON выплюнуть.
Не забудь все 350 столбцов перечислить минимум пять раз в каждом запросе, нервный свитерок.
DECLARE c SCROLL CURSOR FOR select * from t where id > 900000 and id < 1000000;
FETCH FORWARD 5 FROM c;
> Record Count: 5; Execution Time: 0ms
Ты даже не понимаешь над чем я иронизирую из твоего говнОРМ-манямирка.
Вся твоя бизнеса-логика - это одна функция json_agg из PostgreSQL.
Ты хранимку на пять тысяч строк уже закончил, иронизатор? Или она уже не переваривается движком как слишком длинная?
В PostgreSQL нет "хранимок" - https://wiki.postgresql.org/wiki/FAQ#Does_PostgreSQL_have_stored_procedures.3F
Если же ты хотел поиронизировать (если предположить что тебе знакомо это слово) над портянками SQL, про которые ты что-то слышал от кого-то - то может быть тебе самому стоило бы ознакомиться со списком языков, которые поддерживаются (в качестве средств для имплементации user-defined functions), например, PostgreSQL - в них входит и Python, и Java, и Javascript, и Lua, и Си, и Perl, и Tcl, и еще десяток других. И все имеющиеся в них средства организации модульности, разумеется, никуда не деваются.
/dev/null то же самое, только намного быстрее
> In this post, we demonstrate Redis losing 56% of writes during a partition.
Представляю как охуевает оптимизатор от такого зоопарка.
Производительность - знакомо такое слово свитерок?
>Why is "SELECT count(*) FROM bigtable;" slow?
Спасибо, посмеялся.
Перед тем как делать read, обычно надо что-то туда write. И если write туда - примерно то же, что и в /dev/null, то можно делать read сразу из /dev/random - то же самое, только намного быстрее.
>>789532
> оптимизатор
Какие ты слова знаешь, где услышал?
> Представляю
Слабо верится.
> Производительность
Побить производительность говнОРМ, которыми ты в цикле делаешь 100500+ запросов "select by id", а потом 200600+ вытаскивая атрибуты - действительно сложно превзойти.
> Спасибо, посмеялся
Над чем же?
Ты даже не понял что проблема не в count, а в count distinct.
Если тебе действительно* нужно все время получать count, то делай то же, что ты делаешь в любом другом месте, в любой структуре данных, в любом языке и на любой платформе - заводи счетчик и обновляй его при вставке и удалении.
Если же, как это чаще всего бывает, абсолютная точность не нужна, пользуются приблизительными оценками, например https://github.com/aggregateknowledge/postgresql-hll
> For example, in 1280 bytes hll can estimate the count of tens of billions of distinct values with only a few percent error.
Да, точно так же, как и в любом другом языке, на любой платформе, с любыми структурами данных, ничего уникального здесь нет.
> свитерок
Мне нравится как ты пытаешься задеть своего собеседника, демонстрируя с каждым разом все большее отсутствие собственных знаний. Продолжай.
Лалка, не знаю какой ОРМщик тебя выеб в жопу и ты навсегда закрылся в своем манямирке, но в реальном мире никто не "делает в цикле" и знаний у меня вполне достаточно.
Продолжай подшиваться свитерок.
>ты навсегда закрылся в своем манямирке
Почему ты считаешь что знания одних технологий несовместимы со знаниями других? Это проецирование твоих собственных фрустраций по поводу неосвоения возможностей современных СУБД? Хочешь поговорить об этом?
>Ты даже не понял что проблема не в count, а в count distinct.
Не знаю откуда ты вообще это высрал. Но вот какой я лал откапал. Просто лааааааааааааааааааал. Свитера не перестают делать мои дни.
>Почему ты считаешь что знания одних технологий несовместимы со знаниями других?
Поехавшие свитера делают их несовместимыми очень легко одним росчерком:
ВСЯ РАБОТА С БАЗОЙ ДОЛЖНА ВЕСТИСЬ ЧЕРЕЗ ХРАНИМЫЕ ПРОЦЕДУРЫ
и хуй ты им донесешь до их манямирка
a.length
Как узнать размер таблицы?
CREATE FUNCTION count_estimate(query text) RETURNS INTEGER AS
$func$
DECLARE
rec record;
ROWS INTEGER;
BEGIN
FOR rec IN EXECUTE 'EXPLAIN ' || query LOOP
ROWS := SUBSTRING(rec."QUERY PLAN" FROM ' rows=([[:digit:]]+)');
EXIT WHEN ROWS IS NOT NULL;
END LOOP;
RETURN ROWS;
END
$func$ LANGUAGE plpgsql;
(но только приблизительно)
>Как узнать размер массива?
>a.length
Расскажи, как же устроен твой магический массив внутри что в нем нигде не хранится текущий его размер (и отдельно, чаще всего, текущее заполнение - это не одно и то же), и эти нигде не хранящиеся счетчики не обновляются при добавлении или удалении элемента?
И в чем же разница между ними и такими же счетчиками в БД и точно такими же триггерами?
> и хуй ты им донесешь
Похоже, твоей детской психике был нанесен непоправимый удар неосторожно сказаной фразой. Не стоит ли обратиться к специалисту?
Что именно тебя так обрадовало?
Ты обнаружил людей, которые точно так же как ты не понимают как работают конкретные механизмы в конкретном оптимизаторе конкретной СУБД - и радуешься что ты не один в мире долбоеб?
Вместо того чтобы обнаружить некоторый намек на причины, по которым в твоем непростом детстве, которое тебя так травмировало, суровые DBA не подпускали тебя к СУБД ближе чем на дистанцию вызова хранимых процедур, тщательно защищеных от твоего рукожопства и отсутствия необходимых знаний?
>И если write туда - примерно то же, что и в /dev/null
Это если много write в сжатые промежутки времени. Если потихоньку их делать6 но ничего не теряется. Понятно, что задача должна позволять такую роскошь как возможность писать данные не каждую милисекунду, а реже.
Ладно так уж и быть
>И в чем же разница между ними
В том что у нормальных людей все по-человечески сделано, а у свитеров как обычно через жопу.
>Что именно тебя так обрадовало?
То что два абсолютно одинаковых запроса выполняются по-разному потому что смотри пункт выше.
>конкретные механизмы в конкретном оптимизаторе
Если придет конкретный бомж и тебе конкретно насрет на твой конкретный пол - ты тоже будешь радоваться как малый ребенок и разглядывать наваленные завитушки?
>суровые DBA
В своих мокрых свитеро-мечтах
А лучше - раз в неделю.
И каждый раз проверять - записалось ли.
И потом на всякий случай руками копировать на случай если вдруг потеряется.
И записывать не в Redis, а в тетрадочку.
> В том что у нормальных людей все по-человечески сделано, а у свитеров как обычно
В чем же разница?
> два абсолютно одинаковых запроса
Они настолько же "абсолютно одинаковые" как ты и DBA, травмировавший тебя в юности.
>В чем же разница?
Ты видимо совсем тупой. В количестве буков которое надо набрать пользователю api и их очевидности.
>Они настолько же "абсолютно одинаковые" как ты и DBA, травмировавший тебя в юности.
Ну давай покажи мне такой набор данных на котором они выдадут различный результат или мразь гнилая. Хотя можешь не стараться с тобой все и так ясно с первых твоих постов.
Ты про Redis лучше выскажись
чтобы не пердолиться самому с админством
В итоге создал новую бд с дефолтной кодировкой юникод.
Это каждый раз при разворачивании бд надо так ебаться?
Как оно там вообще с кодировками, блджад?
>В количестве буков которое надо набрать пользователю api и их очевидности
Совсем немного, очевидность - очевиднейшая.
http://stackoverflow.com/a/28219043
Ты расскажи сколько тебе придется набрать буковок чтобы в твоем любимом языке "где уже есть такие удобные массивы", обеспечить к этим массивам хотя бы транзакционный доступ и хотя бы самые простые функциональные индексы.
> такой набор данных на котором они выдадут различный результат
Ты совсем уж пизданулся. Эквивалентность действий определяешь как эквивалентность результатов.
https://devcenter.heroku.com/articles/php-support
https://devcenter.heroku.com/articles/heroku-postgresql
Ты еще спроси как заставить стандартную библиотеку танцевать румбу, дибилка.
Не знаю нахуя ты эту ссылку притащил. Кстати триггеры - худшее из дна, но ты видимо туповат и это не понимаешь еще.
>Ты совсем уж пизданулся. Эквивалентность действий определяешь как эквивалентность результатов.
Этим занимается компилятор когда оптимизирует программу, мразь. У свитеромразей такое тоже есть но как обычно работает только через раз и очень хуево, мразь. Кстати как оно - приятно быть гнилой мразью?
Это ведь ты предложил сравнить таблицу СУБД с массивом в твоем любимом ЯП. Вот давай сравнивать честно.
>Не знаю нахуя ты эту ссылку притащил
Там буквы, их можно прочесть. Понимаю что для тебя это слишком невероятное умственное усилие, но ведь эту доску не один ты читаешь.
>триггеры - худшее из дна
Аргументация, как обычно, исчерпывающая.
> Этим занимается компилятор когда оптимизирует программу
И два компилятора с разными наборами ключей компиляции дадут тебе в твоем любимом ЯП два разных ассемблерных листинга.
И точно так же, два разных исходных текста могут превратить наоборот, в один и тот же ассемблерный листинг.
И эквивалентность будет не при чем как в первом, так и во втором случае.
Это ведь самые базовые вещи, ты даже их не понимаешь?
>ты даже их не понимаешь?
Мразь ну хватит уже фантазировать свои маняпроекции. Я когда-нибудь услышу чем эти два запроса принципиально отличаются?
Откуда ВНЕЗАПНО появилось слово "принципиально"? И что оно означает в контексте эквивалентности программных конструкций?
Вычисление факториала с помощью рекурсии и циклов дают одинаковый результат (если их писал не ты и они имплементированы корректно), означает ли это их эквивалентность? Если да - это принципиальная эквивалентность или какая-то другая?
Ну мразь ну плез. Ведь всегда можно сманяврировать - вон смотри там больше букв написано - значит они разные. Я прошу объяснить их отличие в рамках семантики реляционной алгебры.
SQL и реляционная алгебра - достаточно далеко отстоящие друг от друга понятия.
Примерно как теоркатовский моноид в категории эндофункторов и Monad в Haskell.
Ты пока не ответил ни на один мой вопрос, кстати. Последние были про эквивалентность и её принципиальность.
>Ты пока не ответил ни на один мой вопрос, кстати.
А я все жду когда мразь вякнет хоть что-нибудь отдаленно раскрывающее высказывание
>Они настолько же "абсолютно одинаковые" как ты и DBA, травмировавший тебя в юности.
Но ничего кроме прямых репортажей из манямирка и приглашения пофилософствовать на тему "что такое равно" я не наблюдаю.
> Любой кто считает что
> 1. Всю бизнес логику следует хранить в базе
Любой аналитик тебе скажет так же. Потому что бизнес-логики за сотнями строк AbstractProxy...FactoryBean не видно.
> 2. SQL хороший язык программирования
Это язык описания запросов, не самый лучший, но интуитивно понятный.
мимо
У высказываний должен быть какой-то смысл. Ты используешь понятия "эквивалентность" и "принципиальная эквивалентность", тебе их смысл и раскрывать.
>>790151
Ты что-то хотел сказать?
>мимосвитер
пофиксил
>>790159
Ну все мразь включила повышенную маневренность, теперь с ней не совладать.
Мразь, плиз. Хватит уже маневрировать и отвечай на вопрос. Определение эквивалентности можешь взять любое на свой вкус.
На какой вопрос? Почему разные выражения языков программирования после обработки разными оптимизаторами с разными параметрами могут быть оттранслированы в разные конструкции низкого уровня, несмотря на то что неумелый программист мог иметь в обоих случаях ничем не подкрепленое мнение о том что он имел в виду примерно одно и тоже?
Ты не знаешь на него ответа?
Чем отличаются эти два запроса. Не коси под дауна, мразь, даже если для тебя это так легко и непринужденно.
Кстати, в зависимости от разных факторов, например наличия индекса, селективности, кардинальности, статистики, самих данных, настроек, оборудования на котором запущен сервер - результаты твоих двух вариантов count() с SO тоже будут разными - это нормально.
http://sqlfiddle.com/#!15/f263c/1
Роли в данном случае это никакой не играет потому что никто count() всё равно нигде и никогда не использует - это просто тебе в качестве (заранее обреченной на неудачу, конечно) попытки понижения уровня твоего долбоебизма.
Определения эквивалетности мы всё-таки дождемся от тебя или нет? Ты утверждаешь что разные выражения эквивалентны - дай какие-то этому основания.
Их результаты всегда будут одинаковы на любых возможных данных и это очевидно. То что 2+2=4 тебе не надо обосновывать? Если я напишу в программе вместо 4 2+2 должен ли я ожидать изменения в производительности в несколько раз? Или может быть компилятор нормального человека способен на простейшие манипуляции с выражениями в отличии от компилятора свитеромрази.
>Роли в данном случае это никакой не играет потому что никто count() всё равно нигде и никогда не использует
Даа? Что же используют вместо него тогда?
Предвижу дальнейших убогих маняврирований мрази на десяток постов минимум.
То есть ты настаиваешь на эквивалентности программных конструкций на основании тождественности их результатов?
Ты действительно настолько долбоебичен?
Число 4 можно получить бесконечным количеством способов, означает ли это что все эти способы должны выполняться за одинаковое время?
Обычно - ничего, count() практически никогда не нужен.
Реже - приблизительные алгоритмы типа HLL.
В исчезающе редких случаях когда всё-таки нужен точный count() - обычно это ошибка проектирования подобными тебе долбоебами - счетчик и триггер - >>790018
Мразь ты такая тупая что просто некуда деваться. Если ты не видишь никакой разницы между этими двумя примерами то тебе поможет только лоботомия.
Можно было бы предложить такой пример: всякая функция a->a является id. Но ты все равно тупой не поймешь нихуя.
>>790210
Ну если это действительно так и для самой элементарной операцией надо коллекцией какую только можно помыслить нужно городить такие костыли, то все еще хуже в свитероцарстве, чем я раньше думал. Но что то даже не верится.
>всякая функция a->a является id
И поэтому вне зависимости от имплементации любые функции с одинаковой сигнатурой должны выполняться за одинаковое время?
> для самой элементарной операцией надо коллекцией какую только можно помыслить нужно городить такие костыли
Костыли совершенно те же, что и в любом другом языке - >>789637
>И поэтому вне зависимости от имплементации любые функции с одинаковой сигнатурой должны выполняться за одинаковое время?
Я же говорил - нихуя не поймешь.
>Костыли совершенно те же
Я уже написал про различия, зачем ты зацикливаешься, мразь? Место в памяти закончилось?
Ты написал что тебе не нужно реализовывать триггер и поля "занято элементами" и "аллоцировано памяти". В твоем любимом Ruby этого делать действительно не надо - но если бы ты знал хотя бы Си, ты бы понимал что это три строчки - точно так же как и в случае с СУБД - и никакой проблемы никогда и никому это не доставляет.
После этого я задал тебе вопрос - что же предлагает твой любимый ЯП, в котором триттегры и два поля уже есть "из коробки" на тему конкурентного доступа к твоему массиву и его индексации различными способами - потому что раз ты предложил сравнить, то почему же не сравнить - ответа, разумеется, от тебя не поступало.
> Любой аналитик
Любой программист скажет обратное.
> бизнес-логики за сотнями строк AbstractProxy...FactoryBean не видно
Как будто что-то плохое.
Смешная свитеромразь, ты когда-нибудь закончишь юлить пиздой и ответишь на один вопрос которого я добиваюсь у тебя уже постов пятьдесят - распиши мне свой мыслительный процесс - как я должен прийти к тому что второй запрос отличается от первого и должен отработать быстрее, поделись же своим сакральным свитерознанием?
Самое смешное, что я заметил, что обсуждение чем эти два запроса отличаются можно скатить до - ну смотри же там буковки разные - и это ровно то до чего дошла мразь.
>Ты написал что тебе не нужно реализовывать триггер и поля "занято элементами" и "аллоцировано памяти". В твоем любимом Ruby этого делать действительно не надо - но если бы ты знал хотя бы Си, ты бы понимал что это три строчки - точно так же как и в случае с СУБД - и никакой проблемы никогда и никому это не доставляет.
Потому что Сишка - низкоуровневый инструмент. Сравнивать Сишку и СУБД - ну это все пиздец клиника нахуй. Если в СУБД нет простейших средств для работы с данными - ну это хуево значит. Никакой проблемы - ну может быть свитерам чья срака уже так разработана что туда без проблем влезет кластер для репликации.
>После этого я задал тебе вопрос - что же предлагает твой любимый ЯП, в котором триттегры и два поля уже есть "из коробки" на тему конкурентного доступа к твоему массиву и его индексации различными способами - потому что раз ты предложил сравнить, то почему же не сравнить - ответа, разумеется, от тебя не поступало.
Для этого есть конкурентные структуры данных. Если язык позиционируется для таких целей - то они наверняка будут в стандартной библиотеке. Лень даже писать про это, не знаю в какой ты там землянке живешь что об этом не знаешь.
>как я должен прийти к тому что второй запрос отличается от первого
Сделать diff, третий раз говорю. Ну если ты просто визуально не видишь что они разные - воспользуйся автоматикой.
> и должен отработать быстрее
Он не должен. И отрабатывает либо быстрее, либо наоборот, медленнее - в зависимости от, например, наличия индекса - что я тебе продемонстрировал в sqlfiddle.
> я заметил, что обсуждение чем эти два запроса отличаются можно скатить до - ну смотри же там буковки разные
Ты вместо этого предложил считать эквивалентными любые языковые конструкции, которые выдают один и тот же результат. Это тянет на две нобелевские премии и медаль Филдса.
> Сравнивать Сишку и СУБД - ну это все пиздец клиника нахуй
Я тебе, дуралею, показываю что внутри у всех одно и то же - никакой магии нет. Либо ты хранишь счетчик, и получаешь count моментально, либо не хранишь, и надо либо пересчитывать, либо счетчик заводить. В любом языке, на любой платформе. Завести счетчик - три строчки - на любом языке, на любой платформе, в этом тоже нет никакой магии.
> в СУБД нет простейших средств для работы с данными
В СУБД есть не только простейшие средства для работы с данными, но и весьма продвинутые. Которых нет у твоего "обычного массива из Ruby" - или какой у тебя там любимый язык-не-Сишечка.
> Для этого есть конкурентные структуры данных.
Показывай. Вот из того гипотетического языка, который ты все время приводишь в пример, но так его до сих пор и не назвал - стесняешься, наверное. Давай внимательно посмотрим какие в нем конкурентные структуры данных, как они устроены, что позволяют делать, и за счет чего они это позволяют.
И мы с тобой быстро-быстро придем к тому что вариантов всего два - либо они основаны на блокировках, и тогда написание высококонкурентного кода сильно затрудняется - либо на версионности записей (той же по сути MVCC что и в PostgreSQL и Oracle). И за те преимущества, которые даёт версионность, приходится расплачиваться сложностями с distinct count - потому что чудес не бывает.
>как я должен прийти к тому что второй запрос отличается от первого
Сделать diff, третий раз говорю. Ну если ты просто визуально не видишь что они разные - воспользуйся автоматикой.
> и должен отработать быстрее
Он не должен. И отрабатывает либо быстрее, либо наоборот, медленнее - в зависимости от, например, наличия индекса - что я тебе продемонстрировал в sqlfiddle.
> я заметил, что обсуждение чем эти два запроса отличаются можно скатить до - ну смотри же там буковки разные
Ты вместо этого предложил считать эквивалентными любые языковые конструкции, которые выдают один и тот же результат. Это тянет на две нобелевские премии и медаль Филдса.
> Сравнивать Сишку и СУБД - ну это все пиздец клиника нахуй
Я тебе, дуралею, показываю что внутри у всех одно и то же - никакой магии нет. Либо ты хранишь счетчик, и получаешь count моментально, либо не хранишь, и надо либо пересчитывать, либо счетчик заводить. В любом языке, на любой платформе. Завести счетчик - три строчки - на любом языке, на любой платформе, в этом тоже нет никакой магии.
> в СУБД нет простейших средств для работы с данными
В СУБД есть не только простейшие средства для работы с данными, но и весьма продвинутые. Которых нет у твоего "обычного массива из Ruby" - или какой у тебя там любимый язык-не-Сишечка.
> Для этого есть конкурентные структуры данных.
Показывай. Вот из того гипотетического языка, который ты все время приводишь в пример, но так его до сих пор и не назвал - стесняешься, наверное. Давай внимательно посмотрим какие в нем конкурентные структуры данных, как они устроены, что позволяют делать, и за счет чего они это позволяют.
И мы с тобой быстро-быстро придем к тому что вариантов всего два - либо они основаны на блокировках, и тогда написание высококонкурентного кода сильно затрудняется - либо на версионности записей (той же по сути MVCC что и в PostgreSQL и Oracle). И за те преимущества, которые даёт версионность, приходится расплачиваться сложностями с distinct count - потому что чудес не бывает.
Чтобы тебе было проще, можешь начать с показывания в своем гипотетическом языке a.distinct_length() - а не a.length(), как ты настойчиво пытаешься все время то ли передернуть, то ли продемонстрировать собственное непонимание сути проблемы - тут уж не знаю что именно.
Ответа все как не было так и нет. Никаких рассуждений, только если написать 50 разных эквивалентных запросов и посмотреть какой из них будет быстрее. Поэтому нормальные люди и посмеиваются над свитерками.
>Показывай
Нахуй иди мразь. Наша дискуссии и так уже подзатянулась.
>Сделать diff, третий раз говорю.
Значит только буковками, ну все приплыли, мразь.
>Это тянет на две нобелевские премии и медаль Филдса.
Алгебраическое равенство, мразь. Нет, думаю с этим еще арабы разобрались.
>В СУБД есть не только простейшие средства для работы с данными, но и весьма продвинутые.
Ряяя все есть. Как узнать количество элементов? Заведи счетчик ну это же очевидно. Что это? Кто-то там опять пилит новую нескучную СУБД? Но зачем они это делают ведь все и так удобно и отлично работает?
Я к тому, что для вакансия для джуниоров. Стажировок тоже.
Да работа с ним будет очень ограничена спецификой ит-консалтинга. Ну очень. Поэтому думаю просто уебывать.
Не понял. Ты боишься что твоя экспертиза по Greenplum будет не востребована на рынке?
Ну, зависит от рынка и качества экспертизы прежде всего. Вообще интерес к Greenplum большой - Vertica стоит дохуя, Teradatа тоже, а у GP есть интересный community-вариант к тому же, взять который и привлечь местного консалтера - выглядит вполне адекватно.
Не напрягайся мразь
Имхо гринплум выглядит интереснее Терадаты, хотя бы из-за скорости. Да и терадата уж больно заточена на не-сырые данные.
Да, мой опыт будет довольно бесполезным, и я бы с большой радостью ушел бы хоть джуном.
Я знаю около 20 коллег, которые с ней работают, и никому из нас не светит свалить куда-то, т.к. задачи дальше уровня "оценить запрос, как ускорить, создать скрипт сверки" не заходит.
>Если у тебя таблица на 10 миллиардов записей, то издержки связанные с поддержанием индекса в актуальном состоянии будут незаметны на фоне увеличения скорости поиска.
Use partitions, Luke!
Найди хотя бы 10 контор в РФ, где используется Терадата. Это я про потенциальных работодателей.
Он бесплатный? Просто Терадата стоит ебических денег и спецов по ней днем с огнем не сыскать.
ясен хуй что нет, но базируясь на задачах котрые решаются 15к грина в год по сути хуйня.
Терабайт можно на одноюнитном сервере в памяти держать, нахуй вам Терадата для этого?
можно держать, но нужно юзать запросы в рилтайм над этим терабайтом, и еще надо его не проебать по некоторым причинам, еще обслуживать этот ебаный сервер не охота.
Плохое. Ничего хорошего в этом нет.
что такое сервак с теробайтом, который нужно юзать и он должен быть постоянно доступен. Это скорее всего два сервака в колд стэндбае, а лучше 3 еще для ДР, потом мартышка за 30-40к которая нажмет пару кнопок в случае чего, плюс софт который будет мэп рэдюсить за бесплатно с другой мартышкой за 40к, или не бесплатный софт, с другой мартышкой которая будет жать кнопки в нем, ну и где здесь выгода?
За проеб данных в Амазоновском облаке кто отвечает? А если инет упадет, пиздец бизнесу?
все кончно на уровне для энтерпрайз клиентов, но мне лично похуй если глянуть терзво, внутренний ДБА свиторок чем мне ответит за проеб данных? только кляузой об увольнении. Такчто, все относительно.
>ДБА свиторок
Это какой-то локальный мем?
Если есть ДБА, а бэкапов нет, то нахуй его содержать?
т.е. в амазоне один долбоебы, а нащ местный свитерок всех переиграл с бэкапами? Эта и есть суть дисскуссии?
Амазон вряд ли проебет данные, а вот у местных провайдеров каналы регулярно падают. Ну и не всем конторам по закону можно держать данные за бугром.
Ну о Российских конторах тут речь и не идет, много ли в россии контор, которые хотябы бакс готовы заплатить долбоебам из амазона, когда тут свой свитерок с бекапами на чеку?
А о чем тогда речь?
Я не спорю, что это модно, дешево и быстро - хранить все в Амазоне, но вот есть 2 слабых места, неприемлемых для российских контор.
Да мне похуй на российские конторы, я в них не работаю, написал что используем, с терадатой можете ебаться, никакой свой простяцкий сервер вам не поможет сэкономить, потомучто это бля импортозамещение.
>все кончно
С большой буквы. Пропущена буква.
>похуй если
Пропущена запятая.
>Такчто
Пропущен пробел.
Если нужно полное импортозамещение, можно поговорить с PostgresPro про поддержку Citus - https://www.postgrespro.ru/blog/pgsql/27738
С Терадатой необязательно сервер должен быть доступен постоянно - если в ней только OLAP (да и зачем в нее OLTP совать?).
Вы на каждый сервер по джуниор-админу берете? Необычный подход.
> Because of my COBOL background, I have surprised younger programmers by manipulation of strings of data. I have written systems that start off reading a SQL table, then writing to flat files on the local CTemp areas to filter and parse data for exporting to vendors that do printing. Doing that is sometimes easier, and usually much faster that running complex SQL statements to select out the data you need. And it takes the load off the database server
просто ты зашоренный эскуель-дебил
не можешь в nosql mapreduce big data javascript es666 nodejs кококо кукареку кудкудахкудах
против прогресса пидор идеш
плеснул бы тебе из кружки смузи прямо в твое мерзкое ебало
Кто тебе в реляционной СУБД хранить нестрого типизированные (схематизированные) данные? Эффективный XML storage везде есть с лохматых годов, когда никакой монги и на горизонте не было. Эффективный hstore в PostgreSQL с примерно тех же времен.
Сейчас вообще JSONB, еще и быстрее монги работает, и транзакции нормальные.
Редис хорошая же штука, свои задачи выполняет. А сувать туда всё подряд и потом иметь проблемы, как в монгу, и не положено.
Для задач кэша она переусложнена и слишком глюкодромна - классический memcache лучше.
Для задач более серьезных, которые в стране вечного вебодетства пытаются на неё натянуть - ну совсем получается хуита.
Но на слэшдоте речь и не про редис как таковой, а про уровень долбоебизма его типичных пользователей.
Вкратце, есть игра, игроки бывают разных типов - воин, маг, лучник и т.д.
Какая-то часть свойств общая, например, имя, здоровье; какая-то - индидуальна для каждого класса, например, только у воина может быть помощник со своими характеристиками, и таких отличий немало.
Соответственно, я создал таблицу Character с общими полями и полем type, где указываю тип персонажа, и для каждого типа сделал по своей таблице со своими полями, например, Warrior для воина, где уже указаны именно его характеристики, например assistnt_id (id помощника). Делаю связь 1к1 Character и Warror: id - основной ключ для каждой записи в таблице Warrior беру просто такой же, как у родительской записи таблицы Character. Можно ли так делать или же идентификатор не должен копировать родительский?
И я чувствую избыточность этого всего - например, можно было бы не указывать type в Character, т.к. эту информацию можно получить из дочерних таблиц, но не искать же по ним всем, верно?
Ну да, обычно реализуют либо одной таблицей с полным набором свойств, либо так, как сделал ты : дочерними таблицами, которые наследуют(в постгресе только такое видел, не уверен, что есть в мс скл) набор основных полей. А над всеми этими таблицами вешают вьюху, в которой через union all объединяют их по очереди в одну сущность.
Спасибо, вообще, юнионом не хотелось б, у меня там на эктиврекордах работает, иногда приходится дёргать родительскую модель отдельно, что тоже не очень удобно.
А именно дублированные идентификаторы и явное указание дочерней таблицы в каждой записи - это ок?
$time_now = date("H:m:s");
Какой тип данных выбирать для колонки?
И правильно ли я пытаюсь записать данные такого типа в базу?
$query = "INSERT INTO stat (time_now) VALUES ($time_now)";
Явное указание дочереней таблиц - это у тебя справочник с сущностями есть, типа
1. воин, 2. маг, 3. лучник, и в таблице фактов просто стоит айдишник из этого справочника? Если так, то, думаю, да.
Насчёт дублирования - не уверен, что хорошо (если не использовалось наследование), но, честно говоря, сам не вижу другого выхода.
Можно 1. дублировать, а можно 2. вешать другой айдишник и просто ссылаться на родительскую запись. Если второй способ, то это еще одно поле добавляется, так что, наверное, лучше уж продублировать.
Если немножко углубиться, то можно еще пофантазировать на тему того, зачем тебе эти свойства (которые уникальны для каждого героя) и как устроены запросы, которые эти свойства используют?
Потому что, вероятно, можно было всё это устроить в таблице Character_property с полями
1. Character_property_ID - PK
2. Character_ID - FK
3. Character_propert_name
И из нее обращаться любым набором свойств к герою любого типа, будь то воин или маг.
SELECT * FROM stat WHERE datetime_now = (SELECT max(datetime_now) FROM stat)
Достает из базы строку с последней датой.
Как мне достать теперь строку с датой на минуту меньше? Всякие dateadd не работают, ну или я рукожоп.
Тип DATATIME если что.
Ну так ты напиши, что у тебя не работает, а то сам запрос, который не работает, ты не приложил.
В моем примере dateadd работает, как надо
WITH stat AS (
SELECT CAST('2016-01-01 23:59:00.000' AS DATETIME) AS datetime_now
UNION ALL
SELECT CAST('2016-01-01 23:58:00.000' AS DATETIME)
)
SELECT
datetime_now
FROM stat
WHERE datetime_now = DATEADD(MINUTE, -1, (SELECT MAX(datetime_now) FROM stat))
Соответственно из таблицы stat он выведет только ту запись, которая на минуту меньше минимальной.
В общем вот.
Есть таблица, куда каждую минуту добавляются новые строки.
Сначала я беру последнюю строку, смотря по последней дате добавления.
Потом я хочу взять строку, добавленную минуту назад и беру по последний айди - 1, но т.к. иногда там появляются лишние строки, это уже не сработает. Вот мне и нужно брать по дате. Чтобы вычитать из последней даты 1 минуту.
Не знаю правильно ли пояснил, вчера только с БД познакомился.
если у тебя все так детерминированно, почему ты не можешь взять TOP 2 ... ORDER BY [date] DESC?
Ты попробовал, то, что я написал тут? >>795153
Если да, и не работает, то что именно не работает?
Ну у тебя субд mysql, в гугле совсем забанен?
>DATE_ADD('2014-02-13 08:44:21', INTERVAL -1 MINUTE);
http://www.techonthenet.com/mysql/functions/date_add.php
Востребовано. Есть варианты работать по нему.
Сохраняешь id последней... ищешь id на один меньше...
Да и пока транзакция длится, ты не видишь новые строки.
> каждую минуту добавляются новые строки.
> Потом я хочу взять строку, добавленную минуту назад и беру по последний айди - 1, но т.к. иногда там появляются лишние строки, это уже не сработает.
Нет. И не вижу причины почему это "уже не сработает"
ты можешь стопроцентно гарантировать успешность любой из предыдущих транзакций?
Мля, ты будешь что-нибудь отвечать? Или ты один из этих, кто нашел решение и забил хуй без ответа? Помогло или нет?
Сделать автоинкрементный (или другой уникальный) первичный ключ, и столбец пост-ин-тхрэад-айди с уникальным индексом
Либо создавать таблицу для каждого треда
В обоих случаях это будет решение уровня кал
А есть какие-нибудь хорошие решения? Или может на мускул перейти, или сделать общий автоинкремент для всех постов на всех досках?
Очевидно, генерить айдишник, как ключ родительской записи + свой собственный (складываем строки).
не вижу ничего плохого в сквозной нумерации
Таблица одна. Нужно узнать сколько там записей. У меня тупо памяти не хватает отфетчить все и затем посчитать. В монге например есть db.stats(), здесь ищу что-то похожее.
Лол, мог бы и сам догадаться. Грац.
>Ты хотел высокопроизводительную графовую СУБД, пригодную для встраивания?
Она платная, и меня именно это останавливает. На торрентах крякнутой нет случаем?
>MySQL и PHP
>2016
>>797845
А теперь мы всем тредом выслушаем ваши представления о бесплатной СУБД, которую просто втсроить в лешкий интернет-проект.
дибил
Есть какой-то способ по-быстрому (быстрее, чем руками) перебить ID у 1к статей? Подскажите хоть в какую сторону копать, или сколько это стоит и как сформулировать задачу макаке-фрилансеру.
CREATE temp_table AS SELECT * FROM articles WHERE 1 = 0;
-- тут примапливаешь csv с соответствием идентификаторов к базе как external table
CREATE old_id_tbl (old_id NUMBER, new_id NUMBER) ORGANISATION EXTERNAL ...
INSERT INTO temp_table SELECT old_id, .... FROM old_id_tbl o LEFT JOIN articles a ON o.new_id = a.id;
COMMIT;
RENAME TABLE articles TO articles_old;
RENAME TABLE temp_table TO articles;
Но в принципе, имея csv из второго пункта проще будет регуляркой его преобразовать в 1000 UPDATE'ов и прогнать из через консоль.
А вот сам csv сложнее получить - возможно надо сделать джоин через функцию SIMILAR или ту, что ищет похожесть звуков, через заголовки статей. Но если заголовки мигрировали без изменений, то можжно просто джоин по ним сделать.
А также посоветуйте книгу по Oracle PL/SQL для разработчиков (посвежее).
Читай доку, она самая свежая.
Том Кайт. Оракл для профессионалов. Или ещё какая хуйня от Тома, он их несколько запилил.
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:8191916000346674643
> посвежее
Pl/sql так сильно поменялся с 10 по 12 версии?
Как будто оракл не переехал в Индию.
Конференции и её названию уже 42 года, менять они его не собираются.
разве в архитектуре бд важно знание расширения для языка запросов?
Работает кто-нибудь из вас в области КАЧЕСТВА ДАННЫХ?
Предложили перевод в должноть миддла, но выглядит сомнительно. Есть ли перспективы?
>Так чтоб не тупила по 5 сек на каждый запрос.
С индексами или без? Запрос на чтение или запись?
Чтение. С индексами.
А в треде написать, чтобы все могли пользоваться, религия не позволяет?
Тогда твой выбор - это "SQL-EX"
Что насчёт SET IDENTITY_INSERT ON?
Можно же просто вставить те айдишники, которые у статей были.
SET IDENTITY GENDER FLUID;
up
Кому-то нужна книга "mysql+php для чайников", а кому-то "Хранимые процедуры на C в PostgreSQL". Предлагаешь их все перечислить в шапке? Читай документацию, блоги и вопросы на стековерфлоу. Можешь начать с запроса в гугле "твоеназвание_базыданных books stackoverflow", это ведь не сложно, правда?
Хочу порешать, да себе на гит выложить, вотъ лалка.
>Предлагаешь их все перечислить в шапке
Почему нет? В других тредах нормальные объёмные шапки, из которых всё становится понятно, только у вас какой-то обрубок.
Можно было бы расписать про то, какие базы данных для каких целей юзают, в связке с чем и т.п.
SQL Server, если что
сам охуел от того говна, что высрал тут
вот есть у меня таблица со статусами и датами. мне нужно отобрать все, что имеют статус А, В и С, к примеру. далее все это говно группирую по дате и нужно вернуть АСount, BCount и как вы догадались CCount. почему-то мне в голову пришел pivot, но чет я неуверен
есть готовое решение, которое гласит sum(case when status = 'A' then 1 else 0 end), но это пиздец, ящитаю
можно забить на этот вопрос потому, что у меня возник такой: как можно сравнить эффективность/перфоманс двух запросов: через PIVOT/COUNT и через SUM(CASE WHEN)?
план выполнения обоих запросов говорит, что бОльшую часть времени будет занимать сортировка (60%) и поиск по индексам (~40%), что ни о чем не говорит в плане сравнения эффективности.
тестовых данных у меня полторы штуки. есть возможность как-либо аналитически сравнить оба плана, не прибегая к генерации охулиарда фейкоданных?
даже на достаточно слабой, как для сервера, машине оба варианта отрабатывают менее, чем за секунду. действительно ли надо генерировать миллионы записей, чтобы было дело?
Я немного нуб в этом. МОжете посоветовать литературу для чтения, дабы это сделать?
спасиб, анон
Объясните, какой вообще смысл во всех этих орм/персистансах и остальных товарищах?
Я вот всегде все бизнес-процессы с данными выносил в хранимые процедуры на стороне БД и уже из приложения вызывал их по необходимости. Но я в основном работал с ораклом, а там это всё хорошо и производительно на PL\SQL делается.
Т.е. никаких профитов, кроме сомнительной абстракции от БД в итоге нет?
Обычно все сводится к тому, чтобы убрать фуллсканы и заставить работать запрос по индексам, но это какбэ начальный уровень.
Можешь почитать статью:
http://www.fors.ru/upload/magazine/07/http_text/russia_mihjeichev_plan_recomendations.html
Ну пошутил же блядь, ну ебана.
microsoft technet вызывает мучительные муки и нахуй так жить с такой справкой
кошешно нет, зачем тебе установленная субд на месте, где будет работать приложение?
Sql ex же
Юзать индексы, свести к минимуму вложенные запросы, а там, где они есть и возвращают много данных, заменить их на временные таблицы.
Избегать сравнения по строкам, предпочитать айдишники, не забывать про оконные функции, которыми можно решить очень много задач, которые иначе решаются через Ж.
Из моего опыта все.
Гугли
1. Импорт данных (самый нубский способ)
2. Линкед-сервер на Excel-файл - уже интереснее
3. Импорт данных в Sql-сервер через SSIS - самое занимательное, ибо есть интерфейсик, диаграммки и пр. ништяки
4 если извращенец, можно написать макрос в Excel, который будет экспортить данные из него в БД, но это уже не csv, конечно, а xlsmбудет
при попытке запихнуть в туда порядка 1М записей, даже тривиальный SELECT COUNT(Id) (где на Id висит дефолтный кластерный индекс правда этот Id имеет тип UNIQUEIDENTIFIER) выполняется уже секунды. при запихивании 5-6М строк, скорость запроса падает до <30 секунд.
от чего, исключая характеристики железа, может зависеть такое падение производительности несложного запроса? я далек от мысли, что SQL Server не в состоянии из коробки без спецбубна поддерживать подобные размеры таблиц
М - это что?
Внешний ключ смотрит на какую таблицу? Мб у тебя таблица, на которую оьращен форин ки - это справочник из ста миллиардов непроиндексированных записей?
Записи инстертишь в рамках одной базы(одного сервера)?
Сразу приходит в голову затестить скорость инсерта без индексов и сравнить результаты.
M - это миллион
внешний ключ смотрит на таблицу, в которой в лучшем случае ожидается максимум из 30ти записей. но даже если и нет, я же упоминал, что тривиальный SELECT COUNT(Id) работает также ужасно, как и SELECT .. FROM .. LEFT JOIN .. WHERE.. и вот тут, кстати, я подумал о статистике таблицы/индекса. но, покопавшись в гуглах, не нашел вкриков, подтверждающих падение скорости работы из-за неактуальной статистики, внезапно ставшей такой после миллионного инсерта. пока только "если статистика плохая, то". а хуй его знает, чем хорошая отличается от плохой
инсерт происходит в рамках одной базы, конечно
> Сразу приходит в голову затестить скорость инсерта без индексов и сравнить результаты
"без индексов" - ты имеешь ввиду, отключив их? включая кластерный (или с кластерным такая срань не получится?)? ну а что это мне, по сути, даст - плохой джоин, либо переход планировщиком запроса на HASH JOIN и увеличение количества ресурсов на обслуживание запроса?
Чтобы посчитать твой COUNT нужно выгребсти все записи из таблицы. То есть весь миллион или несколько миллионов. Я бы сделал пару сиквенсов. Один для insert'ов, другой для delet'ов. Обновлял бы их триггерами. Число записей определял бы как разницу между числом вставок и удалений. Решение громоздкое, без базара. Вопрос насколько тебе нужен этот COUNT. Может можно без него обойтись? Или сгодится приближенное значение из статистики?
Если ты джойнишь левым джойном маленькую таблицу к большой, запрос будет выполнятся примерно так: для каждой записи большой таблицы ищем соответствующую строку в маленькой. То есть все записи большой таблицы обходятся циклом, если нет where по индексированным колонкам большой таблицы, которые ограничивают размер выборки. Используй лимиты, или ограничь выборку условиями. Тебе ведь не нужен весь миллион записей сразу?
> Вопрос насколько тебе нужен этот COUNT
конкретно count мне и другим) вообще не нужен. передо мной встал вопрос сравнения в плане быстродействия двух разных запросов для отчетов с немалым количеством записей. когда я хотел посмотреть, над каким объемом данных данный момент выполняется манипуляции, тут же оказалось, что сложные (относительно) запросы отрабатывают по времени, сравнимым с подсчетом количества записей в таблице. такой факт стал для меня откровением, чессгря)
>>819366
> Тебе ведь не нужен весь миллион записей сразу?
на данный момент нужен. я верю, что есть более адекватное решение для данного отчета, но пока используем, что используем
> для каждой записи большой таблицы ищем соответствующую строку в маленькой
но ведь построитель запросов умнее, чем среднестатистический пользователь (вроде как) и перемешивает заджоиненные таблицы таким образом, дабы нанести наименьший ущерб производительности. именно для такого случая и придуман хинт FORCE ORDER. ведь так? вангую, привалится сейчас ко мне и еще одно откровение
select count(case status when 'A' then 1 end) acnt,
...
dte
where status in (...)
group by dte
Но если есть индекс на status, то может быть быстрее подзапросами посчитать.
Или же посчитать count по группам дата-статус в WITH AS Select подзапросе, а потом сжоинить но датам.
Братишки, бд-ишки, поясните, пожалуйста, про уровни изоляции в MS SQL, что это такое, с чем едят и т.п.
Msdn не предлагать, там не очень понятно описано.
А что ты хотел от миллиона записей?
Ты видел примеры, где тривиальный каунт выполняется быстрее секунды для таблицы с 1кк записей?
В общем, вполне ожидаемый результат, на мой взгляд. Если нет, приведи пример, где это работает быстрее.
Партиционируй.
Используй таймстампы в запросах.
Не верю что отчету нужен миллион записей они же всегда по ограниченному временному диапазону
википедию предлагать? там чуть понятней написано
>>820092
видел только в маняфантазиях. я ведь уточнял, как мне казалось, это не те объемы, о которые СУБД подобного уровня будут спотыкаться, но..
в любом случае, любой запрос выполняется очень долго, даже если имеет дело только с индексированными столбцами. я вот пытаюсь понять, как так то
>>820119
судя по заверениям клиентов, работа всегда будет происходить с десятками тысяч записей. это была лично моя инициатива протестировать на миллионах
Гугли документацию по %name%SQL DB, там все просто.
>судя по заверениям клиентов, работа всегда будет происходить с десятками тысяч записей. это была лично моя инициатива протестировать на миллионах
Преждевременная оптимизация - плохо. Ты можешь просто рандомом углубиться в А и Б, когда реальной проблемой окажутся В, Г и Д. Задачи оптимизации надо решать на конкретных ситуациях по мере их поступления. Иначе у тебя могут появиться оптимизационные костыли там, где это не обусловлено никакой необходимостью, а это лишние WTF? у разработчиков.
мы, сдается, уже порядком отклонились от моего изначального вопроса) суть была в том, что, начиная с определенного порядка записей в таблице, существенно падает производительность любых запросов: с подсчетом записей, либо с соединением, лиоб с условием по столбцу, не входящему в какой-либо из существующих индексов
меня интересовало, как вычислить/найти тот порог, а главное: почему COUNT() и JOIN-WHERE работают одинаково плохо (хотя мне казалось, что между этими запросами есть гигантская разница).
если этот человек >>819352 прав, то, в принципе, я все понял
> Чтобы посчитать твой COUNT нужно выгребсти все записи из таблицы
Стартует Слэйв, все в порядке, потом встает на определенной позиции и все.
Мастер же в свою очередь идет вперед.
Если сделать слэйв-стоп - слэйв старт, слэйв сразу догоняет эту позицию и идет дальше, пока не остановится опять.
Поставил пропуск всех ошибок, но не помогло. Что может быть?
Да как же вы заебали, ньюфаги.
Куришь Oracle Database Concepts, потом Oracle Administration guide, 732 и 1078 страниц соответственно. Анон, я верю, у тебя получится!
>Я бы сделал пару сиквенсов. Один для insert'ов, другой для delet'ов. Обновлял бы их триггерами.
Вот за это яйца отрывать. Производительность вставки падает минимум на порядок.
очередность полей в индексах и предикатах желательно сохранять. иначе говоря, если фильтруемое поле в индексе идет первым. эффективность такого индекса будет хорошей
Какая субд?
Очень быстрая вставка - это какая? Инсерт онли - это значит, что во время инсерта однозначно не будет обращения к таблице?
С какой частотой будут инсерты у тебя?
Если нужна мега-скорость, то думаю, придется поебаться с Редисом, тут советовать ничего не могу, с ним почти не работал.
А калссически твою задачу можно решить через SSIS + Ms Sql Server:
в SSIS рисуешь свой воркфлоу, как захочешь, и определяешь четкую последовательность этапов. На мой взгляд, очень удобная штука. Но тут, конечно, класическая реляционна субд, мб тебе такая не подходит.
>Какая субд?
Ну riak например.
>Инсерт онли - это значит, что во время инсерта однозначно не будет обращения к таблице?
Смысл такой - конечный автомат на каждом шаге меняет состояние объекта. Соответсвенно на каждом шаге после успешного выполнения необходимо сохранять новое состояние объекта, для реализации возможности восстановления актуального состояния объекта и продолжения работы автомата в случае его аварийного останова. Поскольку необходимо хранить полную историю работы автомата, имеет смысл каждое новое состояние объекта хранить как новую запись. Фактически для каждого процесса исполняемого автоматом создается очередь, в которую на каждом шаге помещается новый элемент. То есть фактически конкуренция за записи в таблце между исполняемыми автоматом процессами отсутствует, просто атомарная вставка нового элемента. Но может быть балковое удаление истории и построение статистики. Можно кончено на реляционой сделать - но будет оверхед.
>С какой частотой будут инсерты у тебя?
Тысячи в секунду. Главное условие - минимальное время на сохранение состояние в общем времени выполнения процесса.
Аноны, ай нид хэйп.
На днях меня ждет собеседование и мне нужно на выходных подтянуть знания по администрированию MSSQL Server (2014 судя по всему). Какую книгу можно скачать по теме? Желательно не для профессионалов этого дела, для новичков. Плюс надо почитать немного о написании процедур на T-SQL. Хэлп!
Аноны, ай нид хэйп.
На днях меня ждет собеседование и мне нужно на выходных подтянуть знания по администрированию MSSQL Server (2014 судя по всему). Какую книгу можно скачать по теме? Желательно не для профессионалов этого дела, для новичков. Плюс надо почитать немного о написании процедур на T-SQL. Хэлп!
Я сейчас уезжаю на все выходные туда, где с интернетами будет туго, нужна именно книга.
ну тада BOL
Сейчас это просто одна таблица с очками, и если требуется выдать топ-100, то я тупо использую ORDER BY. Но ведь эта тема загнется, если записей станет очень много. Как в таком случае поступать? Сделать таблицу с уже отсортированными результатами и периодически в нее сортировать? Сам процесс сортировки тоже займет много времени. Если какие-статьи на тему?
Что приходит в голову, это делать таблицу чанков, с такими полями: score_from, score_to. В начале есть только один чанк от 0 до 10000. При постинге очков система находит нужный чанк, и добавляет запись в него. Если размер чанка становится слишком большим, то он разбивается на два подчанка: score_from .. (score_from + (score_to - score_from) / 2) и (score_from + (score_to - score_from) / 2) .. score_to. А потом система сортирует отдельно только записи в этих чанках.
Какие подводные камни?
Ты протестировал когда она начнет загибаться? Скорее всего на твоих данных не начнет, ORDER BY ... LIMIT 100 не будет сортировать таблицу целиком. Если у тебя действительно такие большие данные/требования по латенси/хуёвая машина что подход с сортировкой начнет загибаться, просто заведи таблицу top_100 (на 100 строчек очевидно) и добавляй/удаляй/апдейти в ней записи на каждое изменение счета. Если измнений очень много тебя спасут батчи/какие-то хитрые оптимизированные sql запросы/МОЩНЫЕ хранимки.
Разве индекс по сортируемому полю не поможет?
Посмотрите на этого уёбка, который пытается построить B-tree на базе данных.
Мудила, сделай индекс и не ссы.
select begin_date, end_date from (select prev_val begin_date, next_val - 1 end_date from (
select prev_val, next_val, row_number() over (partition by grp order by next_val) rn from (
select prev_val, next_val, sum(g_start) over(order by next_val) grp from (
select
lag(time_key + 1) over(order by time_key) prev_val,
time_key next_val,
case when time_key = lag(time_key + 1) over(order by time_key) then 1 else 0 end g_start
from some_table)))
where rn > 1);
Норм?
но ведь самый нижний подзапрос
select
lag(TimeKey + 1) over(order by TimeKey) prev_val,
TimeKey next_val,
case when TimeKey = lag(TimeKey + 1) over(order by TimeKey) then 1 else 0 end g_start
from SomeTable
дает инвалидкастэксепшн:
Сообщение 206, уровень 16, состояние 2, строка 2
Конфликт типов операндов: date несовместим с int
Смысловая нагрузка этих столбцов? По всем выборку делать собрался, индексировать хочешь?
Предметно задачу опиши, что такое Count по двум полям?
Нормально.
Для таблицы фактов - вполне, если почти все столбцы -айдишники(FK)
Для справочника - возможно, если уж у тебя столько важных атрибутов для каждого элемента.
Если у тебя в каждом из ста полей какое-то значение, типа затраты, количество, нормативные расходы, комерч. расходы и так далее, я бы советовал их, все-таки записывать в столбец Value напротив идентификатора, ссылающегося на соответствующий элемент справочника.
Можно, но только в функциях. В одычных запросах только т-скл, только хардкор.
> делать Count c Group by по двум полям и тут же по одному (исключая одно из них)
Через аналитические функции:
> SELECT
> actor_id,
> first_name,
> last_name,
> last_update,
> count() OVER (PARTITION BY first_name, last_name) AS firstLastNameCount,
> count() OVER (PARTITION BY last_name) AS lastNameCounter
> FROM actor
> ORDER BY firstLastNameCount DESC;
> Подскажите, как в MySQL
Никак. Использовать нормальные реляционные БД, позволяющие что-то сложнее круда.
> Никак.
Без подзапросов*
CTE, кстати, тоже не подерживает, так что делай подзапрос. Сделай его еще раз! Еще подзапрос в подзапросе!
С такой частотой не работал никогда, так что тут ничего не могу подсказать. Ребята в стартапе, с которыми я работал, юзали Редис для таких целей, но что-то он больно ебанутый, куча багов, поддерживать сложно.
(SELECT 'first_agg' AS name, COUNT() FROM table GROUP BY x, y) UNION (SELECT 'second_agg' AS name, COUNT() FROM table GROUP BY x) не прокатит? Я вообще в скл не очень шарю
Работать будет (если пофиксить первые колонки в резалт сете), но получится дикая хуйня:
> John--Smith--5 (первая кверя)
> John--Smith--50 (вторая)
И как ты будешь отличать в резалт сете какая строка из какого запроса? Можно ввести суррогатный флаг, но получится еще более дикий костыль, противоречащий философии SQL - ты ебешься с разбором результата, а не формируешь запрос и получаешь нужные данные, которые используешь. Лучше уж через подзапросы.
> name
> first_agg
> second_agg
Что за магические сущности? В результате при группировке могут быть только агреггирующие функции и колонки по которым ты делаешь группировку. То есть в первом запросе x, y, count() (или x, count() / y, count() / count()). Во втором же только х и аггрегирующая функция.
Алсо не получится из второго запроса взять John--Smith--50 (вторая), ибо смит не используется в группировке.
Нахуй нам джон смит? Если я правильно понял вопрос, нам нужно получить количество строк (или джон смитов, не важно) из таблицы, сгруппированой по:
1) полям x, y
2) только по полю x
Мой запрос выбирает это в 2 подзапроса, а чтобы различать строки после объединения - в каждую строку добавляется константное имя как "name". Что не так?
А, ты имеешь в виду суррогатный флаг.
> Что не так?
> Можно ввести суррогатный флаг, но получится еще более дикий костыль, противоречащий философии SQL - ты ебешься с разбором результата, а не формируешь запрос и получаешь нужные данные, которые используешь.
Вот что не так.
> Нахуй нам джон смит?
Джонсмит не нахуй, а нужен. А вот обезличенные строки каунтов с суррогатными флагами нужны вряд ли
> Подскажите, как в MySQL сделать Count c Group by по двум полям и тут же по одному (исключая одно из них), можно ли без подзапроса, если нет, то как эффективнее?
Очевидно, что в резалт сете нужны эти два поля, а не просто строчки обезличенных счетчиков.
>Очевидно, что в резалт сете нужны эти два поля, а не просто строчки обезличенных счетчиков.
Не очевидно. В вопросе про это ничего, так что может и не нужны.
С трудом могу представить нахуя нужна подобная таблица
first_agg 2
first_agg 5
second_agg 40
second_agg 9
second_agg 95
Даже на хуй намотать не получится.
да почему у тебя получается много строк? Каждый подзапрос в моем запросе возвращает одну строку, с результатом COUNT(звездочка) и именем.
> Каждый подзапрос в моем запросе возвращает одну строку, с результатом COUNT(звездочка) и именем.
> одну строку
Даладна.
Ты делаешь группировку по х,у или х.
х--у--z
Джон--Смит--Младший
Джон--Смит--Пидор
Джон--Уеба--Мастер
Тянучка--Еотовна--Шлюха
Тянучка--Еотовна--Шалава
Тянучка--Просто--Блядь
Группировка по х тебе даст
[Джон] secondAgg--3
[Тянучка] secondAgg--3
По ху даст
[Джон--Смит] firstAgg--2
[Тянучка--Еотовна] firstAgg--2
ага, а потом к этой группировке применяю COUNT(звездочка), который возвращает скаляр. Другие же поля я не выбираю
Применение моего запроса к твоим таблицам выдаст следующий результат:
first_agg 2 (по x)
second_agg 4 (по x, y)
Соответственно вот и применение результата:
1 аггрегация - количество тезок по имени
2 аггрегация - количество тезок по имени и фамилии.
Конкретные имена и фамилии нам нахуй ненужны, только статистика
Не, тут я чет напутал. Забей на это сообщение, не ебу что нам дает эта выборка
>>832398
Про груп бай забыл. При группировке твой каунт используется как аггрегирующая функция. Группирующиеся джоны и тянучки аггрегируются по твоему говну, что ты захуячил вместо аггрегирующей функции. То есть считаются джоны и тянучки. Именно джоны И тянучки. Не все люди в таблице. Каунт посчитает всех и вернет 1 строчку если уберешь группировку.
>>832404
Не прошло и двух часов.
COUNT(звездочка) посчитает количество строк в получившейся после группировки таблице. Похуй ему на джонов и тянучек, он всегда вернут скаляр. А так как у нас в селекте только 2 скаляра - "суррогатный флаг" и каунт, то и результатом выборки будет только 1 строка. Проверь запрос, если не веришь
> COUNT(звездочка) посчитает количество строк в получившейся после группировки таблице
А вот хуй тоби. Каунт используется как аггрегирующая функция из-за наличия груп бай. Груп бай убери и будет тебе количество строк.
Заебался я тебе объяснять очевидное. На сакиле выполни запрос и помедитируй над результатом.
SELECT
'second_agg' AS name,
COUNT(*)
FROM actor
GROUP BY first_name;
Да, я чуть ошибся, но результат это не меняет - после UNIONа, одинаковые строки схлопываются в одну, и в итоговом результате - будет 2 строки
> одинаковые строки схлопываются в одну
И у тебя строки
firstAgg 1
firstAgg 1
firstAgg 1
firstAgg 1
firstAgg 1
схлопываются в
firstAgg 1
Без всякого аггрегирования, т.к. юнион склеивает второй результат с первым с сносит дубликаты строк
> в итоговом результате - будет 2 строки
Придурошный, не будет 2 строки.
firstAgg 1
firstAgg 2 не схлопнутся магическим образом в firstAgg 3.
А
firstAgg 1
firstAgg 2
у тебя будет из-за группировки внутреннего селекта и каунта.
В общем, положняк такой. Включи мозги и осознай, или предпочти путь тупого - выполни указанный запрос и после этого выполни твой с юнионом. Медитируй над результатом и пиздуй учить SQL.
А лучше выброси компьютер в окно и не подходи к компьютерной технике примерно никогда, пока как бы чего не вышло.
Как вы понимаете, что он хочет получить? Я так и не увидел, какой результат он ожидает, только посчиать количество тесок по именам и по именам и фамилиям.
Я не понимаю, что в результате он ожидает?
name, null, amount
name, second_name, amount
Так?
> универсальную хранимую процедуру для обновления различных столбцов
В коде приложения напиши абстрактный дао / репозиторий с крудом и конкретные дао / репозитории наследуй от него, и юзай круд, а более сложные методы пиши в конкретных дао.
А не занимайся херней с переносом кода приложения в SP.
А как ты апдейтить хочешь? Различными условиями с кучей кейсов и where-ов или статичными значениями?
Если совсем извращенец, то гугли
>sp_executesql dynamic sql
Если кратко, то генеришь запрос текстом в переменную, а потом подаешь ее, как параметр на вход в эту процедуру.
Есть довольно сложная структура бд, с кучей связей m-n.
В некоторых местах для проверки прав пользователя и некоторых других вещей делать джойны кучи таблиц (пока в самом сложном месте 6 таблиц джойнится)
Есть вариант денормализовать базу, продублировав некоторые связи в массивы айдишек, хранящиеся в нужном ресурсе (бд постгрес). В теории это не вписывается в концепцию РСУБД, но это существенно упростит написание запросов, и я почти уверен, что так же значительно их ускорит. Какие подводные камни?
Денормализовывать надо только тогда, когда у тебя запросы с джойнами заметно дольше работать начинают. А просто так, потому что лень написать пару строчкк - это не причина.
Подводные камни следующие: придется поддерживать кучу процедур для обновления данных по справочникам, например, была в справочнике контрагентов запись: id: 1, name: "Хуй простой", в нем name поменяли на "Хуй обычный", соответственно, в твоей денормализованной таблице, в которой у тебя не только id, но и name хранится, тоже нужно обновить этот name.
В общем, нужно хорошо все обдумать, прежде чем ступать на этот скользкий путь, а то все время будут запросы поступать от пользователей на тему рассинхронизации данных.
В массиве будут храниться только айдишки. Суть такова: есть например таблица files, таблица users, и files_users соответственно. И нужно, чтобы юзер мог видеть и редактировать только файлы, которые на него расшарены. Собственно, такая таблица files_users не одна, а есть различные списки доступа, все сложно в общем. Поэтому я и хочу завести массив айдишек чтобы не джойнить 5-6 таблиц. Обновление массива можно делать через триггеры, или в самом приложении через коллбеки, не суть важно. Причем очевидно связующие таблицы я убирать не буду, т.к. нужны будут выборки и с обратной стороны - но там все просто.
А вьюха с индексами медленная, думаешь, будет? Я бы сначала ее попробовал, прежде чем сразу бросаться в крайности.
БД postgresql.
Есть json объект (рассчитывается вне бд) следующего вида: {1: '011010', 2: '110101', 3: '010101'...}, где ключ - число, значение - битовая строка (длина одинаковая). В БД в таблице есть колонка типа "массив целых чисел", например: [1, 3] Нужно произвести следующую операцию: выбрать из jsona все значения, у которых ключ находится в массиве, и произвести битовое сложение всех значений, т.е., в данном примере выбрать из jsona значения по ключам 1, 3 ('011010', '010101') и получить на выходе '011111'.
сам спросил, сам ответил, кому интересно:
разбить json на 2 массива
SELECT bit_or(b) FROM UNNEST(ARRAY[1, 2, 3], ARRAY['011010', '110101', '010101']::bit(6)[]) AS t(a, b) WHERE a IN (1, 3);
зачем что делал?
Ты генеришь запрос из какой-нибудь пыхи или сидишь в субд mysql и пишешь запросы оттуда?
Хуи сосешь?
а анус тебе не вылизать?
Передо мной(макакой, не знающей SQL) поставили задачу:
1) Нужно отправить запрос на адрес onlyoffice.eu/api/2.0/authentication с параметрами username и password.
2) Получить в ответе от сервера token.
3) При INSERT'e в таблицу автоматически отправлять свеже-добавленные строки(lastname, firstname, email из таблицы USERS) на https://onlyoffice.eu/api/2.0/people, при этом добавив в Header token из предыдущего запроса.
При этом всё это делается в Oracle.
Погуглив, я понял, что выполнить это можно с помощью UTL_HTTP, но разобраться с ним так и не смог. А третий пункт - это нужно создать триггер, который вызовет метод с отправкой файлов.
Да и вообще интересует, это возможно на SQL'e написать?
Можете помочь написать этот запрос, ну, или направить на истинный путь?
Зачем триггер?
Ты же сразу имеешь строку с введенными пользователем данными(фамилия, имя, etc)
Просто жди успешного добавления в таблицу и храни эту заготовочку в памяти.
Для того, чтобы понять, добавил ты или нет, используй блок TRY CATCH.
Если добавил успешно, то отправляй Свою заготовленную строку, вот и все.
На SQL тебе нужно только написать
TRY
INSERT INTO "yourTable"
(Поля таблицы)
select данные добавляемого юзера
Catch print 'NEUDACHA'
После этого инсерта поверяешь, добавилась ли запись, и отправляешь на сервак данные.
Или я чего-то не понял, или все тривиально.
[Flags]
enum Цвета
{Красный=1, Синий=2, Зелёный=4, Фиолетовый=8}
Что для этого нужно сделать?
Пока в голову приходили только тупые нерациональные идеи типа делать таблицу с именем enum'a, в которой указывать в качестве столбцов все возможные значения enum'a и тип столбцов делать bit, а в основной таблице делать внешний ключ на таблицу-enum.
думал просто заменять enum обычным числом - int, и уже в клиентском приложении парсить число и исходя из значения понимать, что в нём было отмечено.
Так оно и должно быть, но другой <string>макакач</string> программист не сделал регистрацию. По итогу регистрация на сайте не работает, а пользователей пока добавляют вручную в базе.
Именно поэтому я не могу написать код на шарпе с отправкой файла на сервер. А приходится выдумывать какую-то хуйню с проверкой добавления в Oracl'e и отправкой из Oracl'a на сервер.
Так вот меня интересует, возможно ли написать такую вещь, которая будет улавливать даже ручные добавления в базу?
>Так вот меня интересует, возможно ли написать такую вещь, которая будет улавливать даже ручные добавления в базу?
>>841335
>Так вот меня интересует, возможно ли написать такую вещь, которая будет улавливать даже ручные добавления в базу?
>>841335
>Так вот меня интересует, возможно ли написать такую вещь, которая будет улавливать даже ручные добавления в базу?
>
>
Да, триггер называется. Только по триггеру не советую отправлять запись через UTL_HTTP. По триггеру проставляй признак на строку, типа нуждается в отправке, а саму отправку сделай в джобе.
Пример работы с UTL_HTTP http://ideone.com/6ETtKF
Двачаю.
Пытаюсь вкатиться в бд. Пощупав mysql и postresql остановился на 2 варианте.
Появились ряд вопросов:
1. В mysql имена таблиц и имена столбцов можно писать в любом регистре и соответственно в запросе не важно в каком регистре писать:
select id, name from users
select Id, Name from Users
При выводе имена столбцов будут в визуально красивом стиле (1 буква заглавная, остальные маленькие)
В postresql же, Users и users это разные имена. Если задавать имена с использованием заглавных букв, то в запросах придётся использовать двойные кавычки (что не очень удобно).
select "Id", "Name" from "Users"
Выключается ли такая регистрозависимость в postresql?
Как принято задавать имена таблиц/столбцов в продакшене (только маленькие/первая заглавная остальные маленькие)?
2. Почему нельзякак изменить тип данных столбца у вновь созданной пустой таблицы?
1. Всё в нижнем регистре. Сам постгрес приводит всё в нижный регистр, что незакавычено.
2. https://www.postgresql.org/docs/9.3/static/ddl-alter.html - 5.5.6
Ага, спасибо.
В mysql после добавления новой строки (через insert) и последующего вызова select * from users новая запись встаёт в правильную позицию в соответствие со своим id.
А в postresql новая запись или обновлённая (через update) встаёт в самый конец не зависимо от id (если обновить запись с id = 1, то она окажется в конце).
Почему так происходит?
А ты задал pk или clustered index для id?
На самом деле, то, как записи лежат в таблице, совершенно ничего не значит, какая разница, как они там расположены?
С точки зрения реляционной теории порядок строк, как и столбцов, не имеет никакого значения. Вставлять в конец быстрее. Нужна сортировка - order by, нужен быстрый поиск - index.
Могут ли несколько сайтов использовать одну бд и одинаковые строки?
Клонировать друг друга*
Да, могут.
SELECT tt., COUNT() dep_total FROM (SELECT dep.name as depname, dep.department_id, po.name as poname, COUNT(*) as post_total FROM department dep INNER JOIN post po ON dep.department_id=po.department_id INNER JOIN designations des ON des.post_id=po.post_id AND des.leave_date is NULL GROUP BY dep.department_id, po.post_id ) as tt GROUP BY tt.department_id;
Считает правильно, но из-за группировки по отделу, показывает только одну должность на отдел. Как быть?
В подзапосе посчитай количество назначений на должность, а в основном сложи эти назначеия для каждого отдела. - Amount
Для этого во внешнем запросе используй SUM(Amount) OVER (PARTITION BY department_id)
Тоже хотел через SUM, но забыл упомянуть, что дело в MySQL, там, я понял, так нельзя. Спасибо
>А ты задал pk для id?
Да, для id установлен первичный ключ
>>841580
>>841624
Вот например у меня 10 записей. Пару записей я обновил и они сдвинулись вниз.
И тут я решил добавить новый столбец id с авто увеличением номера, чтобы не думать о номере.
И после присвоения:
update db_name set <old_id>=<new_id>;
Новые индексы будут в разброс.
Можно как-то привести в порядок бд?
Ты СОВЕРШЕННО не понимаешь в чем суть реляционных БД...
Ясно, если нельзя использовать оконные функции, тогда делай через вложенные запросы:
Посчитай количество Людей в отделе и этот вложенный запрос заджойни к запросу, которым считаешь количество людей на должностях.
Если не понял, напиши названия таблиц и полей, скинем тебе решение.
Вот структура, мне подсказали такой вариант, он работает:
"SELECT dep.name as depname, dep.department_id, po.name as poname, COUNT(des.post_id) as post_total, po.salary as rate ,( SELECT count(1) FROM post po1 JOIN designations des1 ON des1.post_id=po1.post_id AND des1.leave_date is NULL WHERE po1.department_id=dep.department_id ) dep_total FROM department dep INNER JOIN post po ON dep.department_id=po.department_id INNER JOIN designations des ON des.post_id=po.post_id AND des.leave_date is NULL WHERE des.leave_date is NULL GROUP BY dep.department_id, po.post_id"
Или как-то еще проще можно?
Угадайте, где вы окажетесь, если хоть немножко продвинетесь в этом.
Вне рашки?
Господа, у меня потенциально тупой вопрос, но просьба не пинать ногами. Есть сайт, допустим, http://tehnosila.ru/
там группу товаров можно фильтровать по дополнительным опциям, выделенным в категории. Например:
http://tehnosila.ru/catalog/kompjutery_i_orgtehnika/monitory_lcd
разрешения, бренд и диагональ.
Нюанс в том что при выборе опций в одной категории их пересчет не происходит. Он происходит только когда мы начинаем добавлять опции с других категорий.
Суть вопроса: как можно было бы примерно сформулировать такую логику в sql, если это вообще возможно? Имею в виду выборку, т.е. where-блок.
>их пересчет не происходит
Что ты имеешь ввиду? Там очевидный OR внутри фасета (а это фасет, а не категория). При выборе других фасетов идет AND.
>такую логику в sql, если это вообще возможно? Имею в виду выборку, т.е. where-блок.
WHERE item.brand IN ('DELL', 'LG')
AND item.numberOfDmiPorts IN (2)
AND item.color IN ('black', 'white')
Для таких рода выборок и полнотекстового поиска обычно используется solr или elasticsearch.
Заходим на hh.ru.
Находим Техносилу.
Находим вакансию программиста
https://spb.hh.ru/vacancy/18280663
Видим
>Желательно: Hybris, Junit, ZKoss, Apache SOLR, Spring AOP
>SOLR
Что и требовалось доказать.
Спасибо за ответ. Ты прав, в моем случае это эластик и есть готовый запрос. Проблема в том что при аналогичной выборке начинают проседать не выделенные внутри фасета опции, хотя по-идее этого не должно быть.
Интуит, курс эра, там проходишь курсы, изи же, изначальный багаж знаний в виде теории бд, sql, olap (+mdx) желательно иметь.
Да, я разрешаю.
Блять, ты проверял, вообще, свой sql? Он не будет работать элементарно потому, что ты не все поля, к которым не применяешь агрегацию, указал в GROUP BY.
И еще, может быть, я не прав, поправьте, но нет ничего более уебанского, чем выводить в каждой строчке (SELECT ...) как поле.
Это, сука, даже читать невозможно, прибавь сюда еще свою разметку без табуляций и переходов на новую строку, я вот с планшета это читаю, кровью из глаз все лицо залило уже. Если бы я решал твою задачу без возможности использования оконных функций, я бы посчитал отдельно количество сотрудников в каждом отделе и заджойнил этот подзапрос к основному, в котором считалось бы количество сотрудников на должности. Получилось бы что-то типа этого. Пишу с айпада, так что, если где и накосячил в синтаксисе, извиняйте. Поля-атрибуты, типа name и т.п. Я опустил за ненадобностью.
With dep_count as (
Select
Dep.department_id,
Count() as Dep_amount,
From department Dep
Left join Post P ON dep.department_id=P.department_id
Group by Dep.department_id
)
Select
P.post_id,
P.department_id,
count() as post_amount,
DC.Dep_amount
From post P
Left join designations Des on P.post_id = Des.post_id
Left join dep_count DC ON P.department_id = DC.department_id
Group by P.post_id, P.department_id, DC.Dep_amount
Ну и, ясное дело, в Count(...) у меня стояла звездочка, но макаба ее схавала, как тэг разметки-италик.
Божемой, ну перепиши запрос так, чтобы джойн напрямую происходил с подзапросом, такое точно поддерживается. Возьми его в скобки и дай ему такой же алиас.
Селект фром table t
Джойн (подзапрос) sq on t.id=sq.t_id.
Ну и калл же этот май скл, зато бесплатный, хотя, если бы я и выбирал что бесплатное, точно бы остановился на постгресе.
Всё что у меня на данный момент получилось, это найти самый продаваемый тип книг через: SELECT TOP 1 [TYPE], SUM(ytd_sales) AS sales FROM titles GROUP BY [TYPE]
Да, я тупой и ничего не понимаю в sql, даи не преподавали у нас его. Очень надеюсь на вашу помощь, хотя бы советом, как это реализовать, что гуглить. На книги времени нет.
http://rgho.st/8lZp6KV4Z -БД
Точно, спасибо. Даже не заметил что оно неправильно сортировалось. А не подскажешь как мне из этого(на скрине) результата записать business(только само слово типа CHAR, без sales) во временную переменную? Это бы очень упростило мне оставшуюся часть задания.
>>842810
Тот запрос мне подсказали на stackoverflow, сейчас я написал так:
SELECT tt.depname, tt.department_id, p.post_id, p.name as post_name, p.salary as rate, COUNT() as post_total, tt.dep_total
FROM designations de
INNER JOIN post p
ON de.post_id=p.post_id
LEFT JOIN (SELECT dep.department_id,dep.name as depname, COUNT() as dep_total
FROM department dep
INNER JOIN post po
ON dep.department_id=po.department_id
INNER JOIN designations des
ON des.post_id=po.post_id AND des.leave_date is NULL
GROUP BY dep.department_id) as tt
ON tt.department_id=p.department_id
WHERE de.leave_date is NULL
GROUP BY p.department_id, p.post_id;
Спасибо за пинок под зад
Будешь молодец, когда в Group by укажешь все поля, над которыми не совершаешь агрегацию, ты почему-то этого упорно не делаешь.
Ну так выведи города, как в задании написано, что ты звездочку выводишь?
Еще не уверен насчет использования переменных, переменные - это не Т-Скл, если что, а так, для второго дня неплохо. Еще, когда селектишь больше, чем из одной таблицы, используй алиасы, это, вроде как, best practice.
Ну и, если это домашнее задание, которое будет препод проверять, пиши комменты, вообще, в коде всегда пиши комменты, когда описываешь какую-то логику сбора данных, приучишь себя, будешь молодец большой.
1. Расскажи, что сейчас модно для хранения out-of-memory-данных кроме классического B-дерева с LRU и LSMT? Bw-tree - hot or not для не-только-in-memory?
2. Как шардировать данные, чтобы они ещё и нетсплин выдерживали, пусть и со stale read, кроме очевидного хэширования по ключу с репликами бакетов в каждой сети?
3. Атомарные коммиты в распределенной системе -- что есть кроме 2PC?
..., tableA.columnName as choose(case tableB.tagAttribute=0 then 1 else 2, 'incase 1', 'incase 2'),...
но нйет, IDE выдает ошибку мол пшел нах ожидаю select, (, ID или ещё чё то там.
И ещё вопрос, насколько плохо использовать динамические запросы типа
@selectVar varchar(200)=''
select @selectvar+='...'
exec sp_executeSQL @selectVar
1. Без динамик скл - никак.
2. Если можно обойтись без них, то лучше не использовать. Разбирать потом это сам заебешься, так еще и кто-то другой будет читать.
Сам такое ковыряю. Пикрелейтед отлично описывает твой вопрос, думаю. Даже все на экран не поместилось. Но в этом случае, конечно, решение принято правильное. Так что тут уже от ситуации зависит. Можно написать 2 строки на динамик скл, а можно 1000 на обычном. Я бы выбрал первое.
Пасиба.
А нафиг оно надо? Один результат можно поместить в один столбец, другой результат в другой (ав первый null) и всё.
В дальнейших представлениях можно применить тернарный оператор для выбора столбца
having max(sum(ytd_sales)) = ..., не?
В примерах, в команде CREATE TABLE, видел иногда ставится знак ;
Не могу вдуплить, когда его нужно ставить, объясните плес
Пронумеруй результат запроса, взяв группировку по типу и отсортировав по сумме по убыванию и выбери только те записи (назови TYPE_ROW_NUM), у которых этот TYPE_ROW_NUM = 1
Получится 2 вложенных запроса, но работать будет быстро, потому что все вычисления ты будешь проводить только в самом первом:
SELECT FROM (
SELECT
ROW_NUMBER () OVER (PARTITION BY Type ORDER BY Total_sales DESC) AS TYPE_ROW_NUM,
FROM (
SELECT
Type,
SUM(ytd_sales) as Total_sales
FROM titles
GROUP BY
Type
) all_sales
) ranked_sales rs
WHERE rs.TYPE_ROW_NUM = 1
Ставится на логическом завершении команды.
В местах, где кончается твой запрос, например, и начинается новый. Но ты можешь не ставить, ско-сервер за тебя разберется. Просто есть такие субд, которые сами не могут, надо им тогда явно указать.
вики объясняет этот факт
Звучит же круто, сиквел, кяк.
Прохожу курс по основам, очередное задание такое:
Напишите запрос, который выводит все неповторяющиеся в таблице purchase коды продавцов salesperson из таблицы purchase_archive.
Связей между таблицами нет.
salesperson- одноименный столбец в обеих таблицах, причём в purchase столько- то строк, а в purchase_archive на 2 уникальных записи больше. Надо вывести столбец salesperson той таблицы, в которой есть уникальные строки, которых нет в другой таблице, т.е. на выходе должно быть
salesperson
ZZ
JT
Наставник, обещавший отвечать на мои ебанутые вопросы, пинает хуи. Если ты здесь сидишь, знай, что я тебя уничтожу.
Можно еще через except решить задачку:
SELECT
salesperson
FROM purchase_archive
EXCEPT
SELECT
salesperson
FROM purchase
Это копия, сохраненная 18 октября 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.