Влад Животнев: Вот я select любой сложности напишу без вопросов. А вот это "один плейбук запустить" - это не мой сленг. Себе сам настраивал сайт от начала и до конца, потому как нормальных админов во фрилансе не выдел вообще, даже за неадекватные деньги.
Если хотите идеально все сделать - можно и вынести. А так... Ну, прикиньте, сколько у вас товара - если счет на миллионы и будет много дублей - можно. Если нет - я бы не стал.
whats: Тратить время, отвечая на дешевые подколки чуваков, которые не понимают разницы между "есть встроенная функция языка group_concat" и "есть самописная процедура, которую назвали group_concat" я не намерен. Свободны отсюда.
whats: А, ну если реляционные базы не о скорости думают, в акцессе есть group_concat и нормализация не нужна, pk тоже не нужны, вероятно - тогда больше вопросов не имею.
Вы действительно гений, реально разбирающийся в базах, в отличии от меня. Идите домой, всего хорошего.
ну, откуда мы беремся - так из тех же ворот, что и весь народ. Вот вы, например, гений наш - нахрена ему написали запрос на mysql, когда тема - акцесс? Почему вас вообще не смутила изначально кривая структура таблиц? Case, коль уж такой умник, исходя из чего вы использовать не стали, хотя он просил, дать ему + и - вместо текста? Чайнику нужно помогать думать, а не решать за него кривые вопросы, иначе он из чайника превращается в ламера.
А почему вы считаете, коллега, что это отрицательный отзыв? Я его тоже больше положительным вижу - идея хороша, все здорово - конкретно реализовано как фигня, ну явно напрашивается, что "переделайте, будет лучше". Позитив.
А ресурсы на преобразование — тратятся или нет, как полагаете? Лучше всего это заметно как раз тогда, когда создается индекс на миллионы записей — разница будет и очень ощутимая.
А почему ж вставлять данные в таблицу, где нет записей — быстрей, чем в ту, где есть записи?
Не волшебство нам мешает вставлять записи в заполненную таблицу, не оно. А именно что перестройка индекса. Вот это отрицать — и есть самая настоящая глупость. И проверить легко — прибить индекс и убедиться, как же быстро всё стало вставляться.
Что до ошибок — точно так же будем обрабатывать ошибку, как сейчас — т.е. никак. У заявителя никакой транзакции нет на вставку одной записи и никакой гарантии, что оно вставилось. Его система — ему и транзакции делать самому. И никакой разницы в данном случае, на сколь долго лочить таблицу основного лога — нет.
Следите за рукою. Определяем число записей в таблице, допустим, их 12001,
1. берем последний id — 12001.
2. Выбираем все записи меньше чем этот id — естественно, первичным ключем по полю id с автоинкрементом гарантировав их последовательность.
3. Одной транзакцией вставляем это всё в главную таблицу лога.
4. Индекс перестраивается один раз — нам профит.
5. Посколь в выборке участвует малая таблица и берем не всё, а с определенной записи — ничего не мешает продолжать вставлять записи в short_log.
Особенно хорошо заметно это на таблицах не в пару миллионов, а в сотни, с которыми я привык иметь дело.
На этом я эту прекрасную дискуссию прекращаю, бо вы меня не переубедите, а я после «таблица будет работать просто потому, что там нет записей» — не вижу в вас профессионализма и убеждать посему не собираюсь.
«Дата — это по сути тот же инт, верно?» — вот это что написано, о мудрый, а не глупый? Вы, может, сначала попробуете, а потом минусовать будете? Я утверждаю, что вставка записей в таблицу по 10 тысяч за раз — будет работать быстрей, чем по одной. Есть возражения? Далее, я утверждаю, что основная проблема связана с перестройкой индекса — есть возражения?
Только не в стиле: «Это всё глупость!», а именно со всей свойственной вам мудростью: «мол, дело не в индексе, потому что… А дело вот в чем, надо сделать вот это и будет щастье».
А то кроме пока ничем не обоснованной критики — предложений от вас не видно.
Да тут особо смотреть нечего. Простое правило: поля, по которым у вас идут джойны — надо делать числовыми и индексированными, если таблицы будут большими. «wp_postmeta_1.meta_value > 8000» — даже вот это — здесь у вас неявное преобразование. Что будет, если у вас юзер загонит в поле Rent — а оно варчар и позволяет любое значение, скажем, вот это: «цена 9000 рублей» или даже просто «9000р»?
Отработает ваша выборка?
Лучше переделайте сейчас, потому что сейчас — еще не очень поздно, а вот когда вы на это накрутите всю систему — тогда будет реально поздно и неимоверно сложно.
Разработать структуру — могу, в принципе, я делал, например, такую небольшую систему, как Мобильный Банк Сбербанка РФ :)
Но это предмет переговоров в личке.
Их нет потому, что прогнозировать это невозможно. Только предполагать. Вот предполагаете вы, что выполните работу для начальства за один час. А тут приходит другое, куда более высокое начальство и говорит: «бросай все, пошли со мной».
теперь давайте на базу данных это спроецируем:
insert into tbl_supertest(id, value)
select v.id_value, v.value from
tbl_value v
join tbl_valuedetail vd on v.id_value = vd.id_value
сколько времени будет выполнятся подобный запрос на 10 строчках? Политическая проститутка Троцкий скажет: «да за ноль секунд!» — и будет, как всегда, в корне не прав. Блокировочки! Другой процесс взял, и увел таблицу tbl_supertest с собой в режиме — запись запрещена. И? Пока он её не отдаст, никакой работы не будет. Конечно, мы с вами можем посчитать пока скорость выполнения селекта — но это здесь, в самом простом варианте.
А если мы пишем процедуру, и без данных в таблице tbl_supertest — дальше ничего работать не будет вообще? И это еще самый простой вариант.
Теперь пока вы там сидите и пытаетесь выполнить запрос с селектом — приходит еще сто тысяч пользователей и начинают писать в таблицу tbl_value — после чего записей в ней становится не 10, а сто миллионов. А индекс мы забыли с вами создать на tbl_valuedetail.id_value. Отразится это на времени исполнения? А через минуту нас осенило с вами, и мы индекс таки создали. Отразится это на времени исполнения?
И это я еще не учел наличие свободной памяти, скорость вашего жесткого диска, пренебрег фоновыми процессами и еще десятком важных деталей. Понимаете, почему это можно говорить лишь очень грубо?
Не в смысле: «Начальник, отвали с кретинским вопросом!», а в смысле «В мультиюзерной и мультизадачной среде ответить на вопрос ТОЧНО — невозможно. Даете монопольный доступ — будет примерно столько-то».
