Форум PHP

Спасибо огромное!С удовольствием прочту!

начните с нормализации баз данных (нормализации таблиц)
ну и учебник по MySQL от авторов форума не помешает (грубо говоря, точнее очень даже пригодиться ;) )
и самое главное на время изучения Вам придется забыть РНР и остальные языки программирования, знания по ним будут только мешать. Когда используется БД то РНР нужно стремиться использовать только для вывода данных в браузер, весь функционал нужно стремиться перенести на плечи СУБД

Мне кажется что когда 8.000 фотографий в папке нужную тежеловато будет найти)А не подскажите где можно почитать про это фундаментальное строительство БД?

нет не сталкивался, но думаю тут лучше придерживаться правила золотой середины.
под каждую машину папки создавать я бы однозначно не стал.
вообще если честно организация БД (фундамента проекта) - это большая часть работы.

так мысли в слух. У меня еще один вопрос как лучше реализовать хранение фотографий, на этом примере? Можно ли создать одну папку и запихать туда 8.000 фотографий, как реализовано в joomle или будет большая нагрузка на сервер?Меня интересует как реализовано к примеру хранение фото на auto.ru...Это большое кол-во фото в 1 папке или они автоматом создают папки под каждую машину?Сталкивались ли вы хоть раз с этим?

не совсем понял о чем Вы толкуете

можно связать 2 таблицы создав еще одно поле в котором будет понятно к какой группе они принадлежат и выводить фотографии используя это созданное поле...т.е нужно будет создавать типа upload? для того чтобы он массова закидывал фотографии в папку?

вот так бы поступил я изначально:
1 вариант
таблица foto
минимум 4 поля

id_foto | name_foto | alt_foto | title_foto

(про даты создания, размеры и другую служебную инфу речь пока не идет)

потом я бы немного подумал и вынес alt и title в отделные таблицы
для экономии дискового пространства, так как изначально процент их уникальности
был бы маленьким. В последствии если процент уникальности будет переваливать за 80% можно денормализовать таблицу и вернуться к 1 варианту. (хотя это нужно будет устанавливать практически анализируя скорость работы и нагрузки скриптов)

2 вариант
таблица foto

id_foto | name_foto | id_alt | id_title

таблица alt

id_alt | alt_foto

таблица title

id_title | title_foto

___
лирическое отступление
3 вариант
если нужно к одной фотографии организовать более одного alt и title
то нужно добавить еще две промежуточных таблицы

но во всех вариантах таблица foto остается практически неизменной (хотя в 3 варианте поля id_alt | id_title нужно будет убрать) те будет сохраняться связь id_foto | name_foto
чем хороша эта связь:
1 id_foto - это уникальное число и можно добавить хоть 1000000 фотографий с одинаковым именем - это для скрипта всегда будут разные фото (даже если фотки будут физически одинаковые)
2 об уникальности именования фото голова ну никак не болит... об этом заботиться СУБД
3 id_foto можно (и нужно) использовать в качестве имени для хранения фото на диске

А как бы вы поступили бы?Время есть всегда)

мне сложно сказать об этом, так как я не могу вообразить объективных причин по которым я бы попал в такую ситуацию. те изначально я бы делал по- другому.
вот я и пытаюсь стать на Ваше место и хоть как-то "устаканить" образовавшуюся в голове кашу.
сколько времени у меня есть на подумать?