Sauran Baitarakhov, по второй ссылке всё есть, создаешь роль, даёшь этой роли необходимые гранты (там есть цикл на объекты схемы, нужно его немножко доработать, чтобы он включал и другие объекты).
Programmir: лично я считаю, что если логику можно реализовать в БД, то нет смысла городить код, чтобы сделать тоже самое.
Если вам нужно именно это, то почему бы не попробовать? Код всегда можно добавить, а ключ - дропнуть.
Евгений: Количество джойнов само по себе ни на что не влияет, важно то, как запрос выполняется. Смотрите планы выполнения запросов, если там сплошные FULL TABLE SCAN - пора создавать индексы, чтобы информация доставалась только через них.
Andrey Kovalchuk: Такие проблемы масштабируемости решаются кешированием, сегментированием таблиц, распределением нагрузки, затем кластеризацией серверов, межсерверной репликацией, и т.д.
Иван: Это долгосрочная стратегия привлечения покупателя. Если условный шопер будет знать, что с любой покупки в этом магазине ему будут возвращать деньги, он подумает, прежде чем пойти в другой магазин.
wwspb: Отчего же, нормализация - это избавление от избыточности. Составные ключи - вполне обычная часть архитектуры БД. Вот здесь практически ваш пример с паспортом приведен здесь. Только там номер паспорта изначально представлен объединенным.
Можно еще попробовать сделать так, но я не уверен, что это будет работать:
select * from table
where concat(id, name) in (value1, value2...)
wwspb: Потому что пара серия+номер уникальная для каждого человека. Если у вас там автоинкремент на таблице, в которой хранится информация о паспортах людей, то это избыточно.
wwspb: Т.е. у вас есть набор пар серия+номер паспорта (id) и, скажем ФИО (name), вам нужно всю информацию из таблицы только по ним получить?
Если id - это первичный ключ, вам name вообще не нужно использовать для выборки.
Даже если данные вам приходят уже подготовленными, обрабатывайте их повторно и засовывайте в запрос
select * from table
where id in (value1, value2, value3...valueN).
Без разницы сколько строк. Готовьте данные заранее, подставляйте в SQL перед самым выполнением.
Ваши условия нельзя заменить where id >= значение1 and id < значение2, например?
account-1: Любой контент на ютубе - это ролик.
Сами подумайте, например, подаёт абьюзы один-два человека, а загружают контент миллионы людей.
Пока человек пишет жалобу на один ролик, уже залили десяток других. Я утрирую, конечно, но масштабы примерно такие.
Ну и плюс это бесплатная реклама для лейбла, люди послушают альбом на ютубе и купят его потом. При этом, они всё равно имеют право всю монетизацию с таких роликов забрать себе, так что это тройной вин для них - кто-то за них создал аккаунт, загрузил альбом полностью, а они получают с этого и рекламу, и деньги с просмотров.
Если не получается донести до сотрудников собственными силами, можно попробовать сделать это силами начальника :D
Либо каждый раз проверять полученный файл скриптом.
