Влад Животнев: Вот я 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 тысяч за раз — будет работать быстрей, чем по одной. Есть возражения? Далее, я утверждаю, что основная проблема связана с перестройкой индекса — есть возражения?
Только не в стиле: «Это всё глупость!», а именно со всей свойственной вам мудростью: «мол, дело не в индексе, потому что… А дело вот в чем, надо сделать вот это и будет щастье».
А то кроме пока ничем не обоснованной критики — предложений от вас не видно.