Использовать триггера для контроля целостности базы, вместо имеющихся в ней механизмов прямо для этого предназначенных, как бы это помягче... Недостойно настоящего самурая.
wol2for: Могу. За глаза хватит одной только первой книги. Дальше потребуется просто голова. И еще момент - лучше купить печатное издание. В нем поправлены опечатки, а стоит оно сущие копейки.
Коллега, а почему вопрос такой? Вот смотрите, ваши технические возможности должны быть следующие: если не пройдена проверка на моем сайте - СМС не запускается. Да? Тогда это что? Это обычнейшая практика, когда работоспособность приложения возможна только после проверки. Кто только ей не пользуется! И юридически это все абсолютно чисто, особенно, если вы прописываете это в "пользовательском соглашении". Пользователь обязуется использовать только официально купленную программу, нельзя дизассемблировать или иным способо изменять... и так далее - да откройте практически любое лицензиционное соглашение.
Александр Попов: Не так. Уникальный индекс на tbl_user_tag - сделать надо. И надо запомнить, что индекс должен быть на каждое поле, которое участвует в JOIN. Дальше надо просто думать. Например, можно подумать о том, что бы сделать специальную таблицу tbl_tag_search, в нее вставлять список требуемых для поиска тегов и не страдать с тем, сколько переменных будет и как с ними работать.
О май гаш... Да не надо там никакой Count. Also you can use:
select id_user from tbl_user t
where id_user exists (select * from tbl_user_tag i where i.id_user = t.id_user)
Это тоже вернет любого, у кого есть хотя бы один тег.
Жаль, что вы не хотите со мной поспорить, жаль. Про скорость вашего и моих вариантов тоже можем, кстати.
Предлагаю пари. Вот мы взрослые люди, поэтому - я ставлю одну тысячу долларов на то, что допишу ровно одну строку без всяких distinct к своему решению, и будут верно отобраны все результаты плюс не надо будет лезть в код при каждом добавлении нового тега или удалении существующего.
Согласны ли вы, коллега, что в вашем варианте в код таки лезть придется? А поддержать меня своей ставкой, пусть даже и меньшей? :)
Именно. Оно для варианта "или", явно короче, чем тот вариант, чем у вас и лишен всех недостатков, о которых я писал. Для варианта И, я считаю, топик-стартер должен сам просто чуть-чуть подумать.
Решение на поверхности.
Но вот что совершенно справедливо, коллега, вы отметили - так это то, что в варианте топик-стартера нет уникальности на сочетание юзер-таг. На моей выборке это никак не скажется, но если можно несколько одинаковых тегов добавить одному юзеру - база спроектированна неверно. Что надо сделать? Добавить уникальный индекс на id_user + id_tag.
Вот который раз смотрю и прошлый раз не сдержался, а в этот прямо напишу: ну вот на кой черт советовать, если вы пока не разбираетесь в теме? Что он получит в вашем прекрасном варианте с "прилепленными" джойнами? Не получится ли так, случайно, что один и тот же юзер ему будет возвращаться N-ное число раз? И придется как раз применять DISTINCT, что еще более замедлит выборку?
Любой код, который выглядит некрасиво - скорее всего, и работает неверно. А ваш код выглядит отвратительно и повторяется. Повторение кода - это второй и еще более верный признак того, что делается все через левую пятку.
Что произойдет, если в вашем варианте добавится еще один таг? Потребуется лезть в код и дописывать его. Третий, итоговый признак того, что вот так делать нельзя.
строго говоря, они ускорятся не потому, что будут интовые, а потому, что будут искаться не в таблице, а в индексе. Упоминание про INT здесь для того, чтобы вы именно этот тип данных выбрали.
Извинения приняты, а вот ответ как ответ - так и не помечен.
Глеб, Вот я говорю: select * from tbl_cooltable. Где выполняется запрос? На стороне сервера. Куда идут данные? Вызывателю. Сколько их пойдет? Все. Миллион.
Теперь я говорю: select * from tbl_cooltable where Id_department = 79 and date_action > '20161101' (год-месяц-день) Где выполнится запрос? На стороне сервера. Куда пойдут данные? Вызывателю.
Но пойдут они уже по условию. А значит, их будет не миллион, а несколько тысяч. Это первый момент.
Второе - если добавить индекс по этим двум полям, то выборка ускорится, потому что оба этих поля будут INT. Если же в этот индекс добавить еще и нужные вам поля - то будет счастье еще больше.
Третье: если оформить это еще и процедурой - то будет еще и зараннее откомпилированный запрос, что еще больше ускорит эту выборку.
Работы тут реально на три часа, из которых два с половиной уйдут на нормализацию и индексирование ваших данных.
:) Вообще любой запрос на стороне сервера, (а процедура - это стопроцентная сторона сервера), все передаст именно на него.
Количество столбцов, разумеется, тоже влияет на производительность. И еще на производительность выборки влияет то, покрывается ли она индексом.
Я бы сделал индекс, покрывающий конкретно вашу задачу. Т.е. поля - Id_department, Date_action, а вот остальные поля, необходимые в выборке, пошли бы у меня в INCLUDE.
Что, собственно, и требовалось доказать. Вся куча данных валится на эксел, от чего ему и плохеет. А я как сказал?
Сделайте локальный сервер, не нужен никакой Azure.
Залейте туда ваши данные.
Пронумеруйте ваши филиалы от 1 до 100
Назовите это поле в таблице как Id_Department, например.
Сделайте индекс по нему и дате, можно - включающий необходимые данные.
Далее пишется select, в идеале - процедура. В нее передается Id_Department и дата.
И тогда: данные выбираются и обрабатываются на стороне сервера! Серверу миллион записей - раз плюнуть, он на миллиарды способен.
А вот на эксел будет тянуться только результат обработки.
И неженственный. Мое решение - работает. Именно поэтому я эксперт в этой теме. Вот что не работает _ваше_ решение по предложенной мной идее - в это охотно верю.
Предлагаю пари. Ваши $500 против моей $1000. Я беру базу с нормально залитыми данными, нормальное ТЗ и выкатываю результат максимум через 3 часа.
Ну? Чистый заработок, деньги просто валяются на земле, вам остается просто их подобрать!
Доброго. Вот пара логин-пароль выбрана. superuser/Zj78!#G648 Вход типа осуществлен. Поставили пометку 02-07-2017 8-46.
Чудно. Ищем следующего... И тут происходит разрыв связи у superuser. А метка, что он в базе, стоит...
Что делать?
Теперь цикл. Как правильно сказали, цикл делать не надо. Структура должна быть типа такого
Id login_name pass_word login_date_time
1 superuser Zj78!#G648 NULL
Пароль причем шифруем.
Далее делаем процедуру. Диалект sql - t-sql. Для mysql использовать limit
select top 1 login_name, pass_word from tbl_cool_table where login_date_time is null
Вот такой запрос вернет вам ровно одну строку с человеком, который еще не в базе
При втором запуске - еще одну строку с человеком, который еще не в базе. И так до тех пор, пока есть хоть кто-то, у кого login_date_time пустой.
Аналитик для написания техзадания на любом более-менее крупном проекте ОБЯЗАТЕЛЕН. Плюс толковый тестер, особенно в случае, если вы не программисты. Технический директор вам не нужен, вам нужен толковый технический писатель, плюс, как я вижу, разработчик интерфейсов. На первой стадии вы собираете свои хотелки, он их записывает, объясняет, почему так вот сделать нельзя, а вот тут надо поправить и сделать иначе, рисует все формы - и только после утверждения всей этой красоты, можно давать что-то в разработку.
