хм, неожиданно, но тут уже вопрос что нужно - точно "не отдавать любой ценой", или "а, покатит, зато работает быстро!". В идеале сайты с такой системой используют оба подхода.
нет. group_id вносим ручками, это объединяющий ключ для записей на разных языках, т.е. при создании новой записи делаем выборку max(group_id) из базы, добавляем 1, создаем новую запись в базу с этим group_id, теперь у нас этот групид забинден для этой новости, при редактировании можно переключиться на другой язык и вписать новость на нем, тогда групид будет браться из урл, а не создаваться по новой, а у новой записи будет лангид другой.
нет, на каждую новость на 1 языке все равно надо будет делать отдельное добавление, например если у вас будет новость только на одном языке, или допустим будут 2 админа, каждый для своего языка, короче много есть нюансов, у меня реализовано как 1 форма с полями, + ссылки на все языки ввода новости над формой, например ссылка на редактирование новости на украинском с group_id = 6 у меня будет выглядеть так: mysite.dom/admin/news/edit/6/2, на русском /6/1
индексы по обоим полям, выборки по ним будут интенсивными.
И отпишитесь здесь заодно о замерах скорости выборки такого джоина, а то что -то наводит на мысль что такое количество джоинов на каком-то этапе сильно притормозит. Буду благодарен за конкретные цифры по скорости запросов / количеству записей.
Точнее в 2 и более ) не понимаю в чем проблема, Вы как будто платите за каждый байт базы... УТФ не зря придумана, а с современной стоимостью дискового пространства размер базы - последнее о чем надо переживать сайту с объемами информации меньше чем у вк и фб.
hdtor: дык, а как ты хотел, тут уже нужно по-другому, проверять что идет после твоего /ru в коде и подключать тот же login.php инклюдом например. Итого, получаем черезжопный парсер ) Потом понимаем что любой конь в пальто может вставить вместо Login какой-то другой скрипт - и (ТА-ДААА!!) думаем над моделью защиты от таких экспериментаторов, например какая- то прослойка с загрузкой только разрешенных модулей ... А там глядишь и код с представлением разделить додумаемся... И про объекты почитаем, глядишь - еще один из кодеров до программиста дорос...
на создание объекта "налету" уходят ресурсы, плюс выделяется время гарбеджера, а статик методы создаются сразу при запуске приложения, и мусоркой не обслуживаются, плюс еще несколько нюансов, в целом статик очень близок к массиву и по внутренней структуре, к его свойствам даже можно обращаться как к массиву.
извините случайно нажал ввод )) вставляйте конструкцию из кусков html и пхп вставок, примерно так, и тогда код будет нагляднее:
while($row=mysql_fetch_array($result)){ ?>
Текст
Так и хочется ответить "ДА!" )
С такими вопросами Вам на битву экстрасенсов надо, там телепаты посерьёзнее,
ибо что все-же нужно? автоматически скачать файл на сервер? Открыть курлом и пропарсить? просто поделились радостью от существования апи и тем что его можно открывать курлом?
Был у нас такой проект, много нюансов было, и мс было выбрано осознанно, и не без оснований, и работало как надо, запилить все это на мускуле на тот момент было нереально, но там были свои сервера, 1 ламп + вин2000серв и мсскл, денег платил буржуй, на аппаратно-программную часть денег выделяли сколько надо, тут же, видимо, случилась ошибка планирования на этапе подбора программных решений, ибо, раз бабла на серв не предполагалось, каким боком там появился(и нафига сегодня??) мс остается загадкой...
нет, оба раза мимо ) Картинки хранятся уже маленькие в кэше СЕРВЕРА, при первом обращении к картинке сервер создает ее маленькую копию "на лету" и помещает в СВОЙ кэш, при повторном обращении сервак просто берет эту готовую картинку, занимает ОЧЕНЬ мало времени, т.к. nginx оптимизирован для работы со статичным контентом и большим кэшем. Рекомендуется к прочтению. Это решение снимает проблему хранения превью в папке с основными картинками, логикой создания этих превью и местом на диске (через время кэш картинок удалится, место освободится, если кто-то зайдет на старые новости - картинки еще раз пересоздадутся), внимательно читаем тут
