Юрий, дело в том, что и ТС подозреваю, не знает полной картины до запуска сайта. А потом окажется, что какие-то объекты не имеют англоязычной версии вовсе, например. С указанным "первым вариантом" это не проблема. Или понадобится добавить немного белорусского или венгерского...
Как говорил Азимов, "число два не имеет смысла". В программировании это очень важная концепция - не стоит рассчитывать на то, что чего-то всегда будет конечное количество, если его уже на этапе проектирования больше одного. С поправкой на здравый смысл, конечно.
Лучше или хуже не бывает абстрактно. Нужно смотреть использование базы.
Например, во втором варианте вам при каждой выборке нужно будет джойниться с таблицей локализаций, чтобы убедиться, что выбранная хата присутствует в текущей локали. В первом достаточно еще одного условия по проиндексированному полю.
Чувак. Найди учебник. С примерами. И поделай сам.
Напиши что-нибудь, что будет работать.
А если тебя интересуют указатели - то что-нибудь, чему они для работы нужны.
И вопросы если не пропадут совсем, то станут менее тупыми.
Ты даже не учишь язык по Тостеру, ты просто тратишь чужое время на свои фантазии.
Свое, кстати, тоже. Впустую.
Куда уж более на пальцах? Учебник почитайте.
Звездочка после типа - указатель на этот тип (переменная, в которой хранится адрес в памяти другой переменной). Вторая звездочка - указатель на указатель (переменная, в которой хранится адрес переменной, в которой хранится адрес).
Звездочка перед именем переменной - разыменование указателя. То есть подстановка вместо этой переменной того, что лежит по тому адресу, который в ней сохранен.
Скобки помогают понять, в каком порядке должны быть применены звездочки. Кроме того, тип в скобках перед переменной - это принудительное приведение переменной к этому типу.
Алексей, разница в том, что я бы не смог написать такую дичь даже в качестве примера.
Ну, и как я уже писал выше, 13 проверок не нужны в принципе.
Да и айПад упадет не в любом случае, а только в том, когда программист считает, что память безгранична.
Алексей, и при этом программист даже в примитивном алгоритме пишет 13 if вместо одного цикла...
То-то браузер на моем стареньком айПаде все чаще просто падает на современных сайтах от нехватки памяти.
Насколько я знаю SQL, LIMIT 0, 100 совершенно необязательно выдаст вам первые 100 id по порядку.
Для этого нужно уточнить ORDER BY id.
Ну, и два запроса к одной и той же таблице, чтобы сначала выбрать id, а потом строки с ними - это уже за гранью где-то. Дайте угадаю - потом еще идет третий, UPDATE? Или - по UPDATE на каждую строчку?
Может, лучше озвучить саму задачу?
Я правильно понял, что вам нужно не только выбрать события, но и разложить по дням?
Тогда так:
1. определяем unixtime последней полуночи.
2. для каждого события определяем, сколько дней назад оно произошло (вычитаем из значения п. 1, делим на сутки в секундах). Будет кривить при переводе часов, но не похоже, чтобы вы были готовы к таким тонкостям.
3. если полученное значение от 0 до 13 - добавляете это событие к списку. Собственно, все.
Для устранения кривизны п. 2 таки придется покопаться в учебниках или библиотеках, но это совсем другая история.
