ztxn

>>Стоит ли в этом случае делает индекс составным и кластеризованным?
Составной индекс по паре (time, account), для отбора по экаунту наверняка вам будет бесполезен. А для отбора по экаунту и диапазону времени (или с сортировкой по времени и отсечкой по top/значению времени), он будет существенно менее эффективен нежели по паре (account, time)

Наверняка отбор по экаунту производится с сортировкой по time и отсечкой по time либо же top, либо же по диапазону time. В этом случае, мне думается, будет уместен составной индекс по паре (account,time)

Вот кластеризованный — ли, берут меня сомнения. Нужны дли вам на столько дополнительные пять копеек при отборе, чтобы можно было чуть пожертвовать производитеьностью на вставке? Полагаю — врядли. Скорость вставки, мне думается, тут весьма критична будет.

Нет, не то, тогда полное соответствие требованиям будет равняться по рангу полному не соответствию. Надо еще подумать

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

select навыки_вакансии.вакансия
       ,требования_резюме.резюме
       ,count(*) as ранг
from навыки_вакансии,требования_резюме
where  навыки_вакансии.показатель = требования_резюме.показатель
group by навыки_вакансии.вакансия, требования_резюме.резюме
order by ранг desc

>>Правда ли что чем больше партиций тем, по идее, выше производительность но больше занимает места?

нет не правда. В общем случае секционирование черевато просадкой по производительности. Лишь в частных случаях оно может дать выигрыш.

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

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

>> У таблицы есть «группирующие» поле
Не совсем понятно что вы имеете тут в виду. Если вы группируетесь по полю, которое является ключом секционирования, вероятнее всего вам придется сканировать весь набор записей, все секции, и первый, описанный мною случай, выигрыша в производительности тогда, определенно, не про вас. Я очень сомневаюсь что MySql способен, как оракл, параллелить выполнение стейтмента, потому и второй описанный случай выигрыша, тоже врядли о вас.

Зачем вообще делать хэширование, держать набор на клиенте, если у вас есть первичный ключ?

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

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

>>Какая из этих структур более предпочтительна для организации программы учета.

Учет подразумевает еще и ведение каких-то преаггрегаций. Запасы, состояния счетов и пр пр.

В случае, когда используется первая структура, для каждого типа документов должна быть реализована своя собственаня процедура проведения по остаткам. В результате, пересчитать все остатки по документам или же выявить какими документам сформировался некий текущий остаток, оказывается достаточно проблемотично. Чтобы как-то унифицировать расчет остатка, упростить отслеживание того, как остаток формируется, придется лепить еще одну суррогатную сущность — проводку, для каждого из разрезов остатков. И ссылаться эта проводка будет на разные структуры данных, что очень не канонично, целостность стандартными средствами не проконтролируешь.

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

Я видел несколько систем, где транзакционные документы сохраняются в трех структурах. 1 — Документы с внешними контрагентами — документы купли/продажи 2) Внутренние документы — перемещения между складами/зонами внутри организации, изменение статуса товара, списания всяческие и пр. 3) Фискальные документы, сиречь чеки. Мне такой подход кажется наиболее подходящим для большинства задач, с которыми мне приходилось сталкиваться.

select name
   ,max(case when phone_type = 'home' then phone end) as home
   ,max(case when phone_type = 'mobile' then phone end) as mobile
from table
group by name

выбрать category_id того заказа, у которого min(«order».created)

select customer_id, created, category_id 
from 
  (select customer_id, date_trunc('day', «order».created) as created, category_id 
          ,row_number() over (partition by customer_id order by date_trunc('day', «order».created)) rn
   from «order»)s
where rn = 1

Я правильно понимаю, что используя термины «бд»,«база» вы подразумеваете «таблица»?

Если так, можно посмотреть в сторону секционирования.

Можно

select * from статьи t
where :n > (select count(*) from статьи s where s.автор = t.автор and s.id<t.id)

Но решение с несколькими запросами с клиента будет куда производительнее.

Возможно тут еще как-то можно применить трюк с переменными…

Спасибо за этот вопрос. Не знал об этой плюшке PG.

Печально, что caveats сужают область ее применения до ничтожно узкой.

в лоб
upper(`username`) LIKE upper('%jNC%')

но вообще dev.mysql.com/doc/refman/5.6/en/case-sensitivity.html

1) состоящих более из 7 слов

Без регекспов:
Если разделители пробелы, количество слов = length(str)-length(replace(str,' ','')) + 1
Убрать дублирующиеся пробелы можно как-то так: replace(replace(replace(str,' ','~ '),' ~',''),'~','')

select *
from (select str,replace(replace(replace(str,' ','~ '),' ~',''),'~','') sstr from t) s
where length(sstr)-length(replace(sstr,' ','')) +1 > 7

Регекспами:
select * from t where ' '||str ~ '(\s+\S+){8,}'

2) содержащих только символы от 'a' до 'z', от 'а' до 'я', цифры и знак '-'

select * from t where str ~ '^[-\w\dа-я]+$'

Пг — версионник, у него запись не блокирует чтение, MS — блокировочник. Изоляция транзакций реализована совершенно по разному.

Простой пример:
ms, выполняя запрос insert into table (value) select max(value) +1 from table, в read commited не допустит дублирования значений при вставке несколькими сессиями, а в PG — запросто.

В этом контексте на MySQL может оказаться переехать куда проще. Он тоже блокировочник.

Я припоминаю в памятке абонента, которая прилагалась к симке много-много лет назад, когда я подключался, была оговорка, что-то вроде того, мол тарификация производится по данным о длителности соединения от коммутационного узла, и эти данные, порой, могут существенно отличаться от показений мобильного телефона.
Однако пруфа, увы, сейчас найти, как ни старслся, — не смог.

Все же полагаю, врядли вам стоит апеллировать к показаниям устройства, даже если устройство безупречно.