Я бы Вам порекомендовал, табличку authors (id, name, description) немного дополнить.
Ввести поле в которое сразу записывать 1 букву имени, сделать по нему индекс. Тогда таблица будет что-то типа authors (id, name,firstLetter, description)
Это нужно для того чтобы выборка по первой букве происходила не через like. На большой таблице будет тормозить
Этот запрос вернет все новости. Хотя по идее должно быть условие не ворачивать новости в которых дата публикации > текущей даты, плюс новости которые скрыты?
Я просто к тому, что надо предусмотреть условие к этому запросу...
Давайте так DeepVarvar и etoYA договоримся. В принципе проблему я обозначил. Если не будет ответов. Я вечерком(или завтра) напишу Вам в личку. Может Илья потом статью напишет.
Просто мне надо все проверить. EXPLAIN и т.д
А вот тут я бы очень хотел услышать мнение "старших товарищей". Здесь нет сарказма если что. Я делаю поле в котором проставляю № страницы. Тут только проблема, что тяжелые процедуры в админке получаются
Еще академический вопрос
Вот Вы советуете InnoDB. Я читал про одно и про другое(MyISAM и InnoDB). В данной ситуации я думаю, что лучше будет именно MyISAM, т.к добавление в таблицу будет не так часто, UPDATE тоже.В основном все запросы будут SELECT. Почему же по Вашему мнению лучше InnoDB?
EuGen
В таком случае да. Но если ключ это оочень длинная строка ~1000 символов, и нужно извлечь ее и с ней работать то не о каком хешировании не может быть речи.
Но представить ситуацию, когда это надо не могу.
Bio man Зачем вот смотри. Есть "предполагаемый" массив
Как хранятся массивы( ключи) можно прочитать на хабре коротко $array['key']-->hash таблица
Идем дальше.
Зачем нам это?
Можно сделать проще:
Ключом сделать hash
А первым элементом истинное значение, тогда получится следующее