Наталия: дай то бог, а то это просто адский ад какой-то, я так в начале 90 учился, ясное дело тогда не было нормального ооп, да и книг нормальных днем с огнем, но сегодня инфы нормальной море, все под ооп заточено, учитесь сразу правильному стилю.
Arik: Это самый правильный путь, скажем так - для удобства вы можете создать 2 модели(допустим чтобы проще визуально воспринимать и разделять логику), но записи в базе будут в одной таблице, т.к. в храниении данных разницы нет, значит они ничем не отличаются кроме 1 поля в бд, и, соответственно, различий не больше чем между машинами разных цветов.
Maximys781: Слабенько понял, уж извини, но твой вопрос и комментарии говорят о том что в понимании процесса у тебя огромная дыра, то есть для начала почитай как работает, потом уже пытайся написать. Понимания как работает серверсайд и объекты у тебя нету, отсюда и вопрос, который смотрится как "я в ухе гвоздиком ковырял - бац, звук у телека пропал, как починить телевизор?". Надо понимать что от чего работает, а не куда тыкнуть что бы заработало.
BelOFF007: ээ, то есть выбрать 150 последних ид и сделать "селект ин" передав 150 идишников нагружено??? Это должно работать просто мегабыстро, даже с учетом мускуль-пых-мускуль, или где то косяк с индексами, или вы делаете что то не так. В крайнем случае можно использовать джойн, ссылка в ответе.
AlxMrz: при приведении кода в комментариях используйте оборачивание в тег code (как в форме ответа) , это не дает коду "выполняться" и код не обрывается.
dllweb: возможно сессия из соседней вкладки сработает, точно не скажу, надо пробовать, я никогда такой хренью не занимался, нужно длинный цикл - кидай в отдельный поток, при завершении сохрани результат, при запросе выведи.
Роман Мирр: если человек об этом не думает, то какой он нафиг программист, пусть наймет спецов, хотя конечно и по вопросу понятно что пока не очень опытный...
Maloy123: если есть строгая необходимость получить однозначно неизмененные данные делается лок таблицы и транзакция выборок, но это уже совсем хардкор. Теоретически у вас в базе была верная информация до изменения данных, после изменения они стали более актуальными, но старые были верны пол секунды назад! ТО ЕСТЬ КЛИЕНТ НА СЕКУНДУ РАНЬШЕ ПОЛУЧИЛ БЫ ПЛОХИЕ ДАННЫЕ? Нет. Я знаю чрезвычайно мало областей применения такого инфопотока где требуется миллисекундная точность данных.
Максим Гречушников: умножение оно такое, вроде не много, а потом бац-чета запросы тормозят. И кроме того - тут в выводе не плоский массив, что сразу исключает объединение таблиц.
