хранение фото

Ссылки на фотки храни в отдельной таблице, что-то вроде этого:
FotoID, UserID, FileName

Создай директорию и сливай туда фотки. Чтобы сделать имя уникальным давай им имена состоящие из времени Юникс плюс случайная строка длиной 4-8 символов.

Юзеров храни в отдельной таблице. Пускай она будет иметь много полей - это ничего страшного. У нас например таблица хранящая юзеров имеет 47 полей.
Что-то вроде:
UserID, Login, Password, Nickname, Name, Surname, Middlename, birthday, sex, city, country, .....

то есть в поле FileName храню имена фоток. окей. спасибо за ответ!
а как насчет переписки между пользователями?

[QUOTE=Scottie]то есть в поле FileName храню имена фоток. окей. спасибо за ответ!
а как насчет переписки между пользователями?[/QUOTE]
Ну я бы стал делать какую-нибудь систему хранения сообщений... Тут уже надо думать побольше...
Не буду утверждать что структура верна (зависит от конкретного ТЗ), но что-то вроде:
FromUserID, ToUserID, SendTime, ReceiveTime, Message,....

Позвольте выскажу своё мнение. Считаю что хранить информацияю в одной таблице не стоит, хотя бы потому, что вся информация не нужна всякий раз при обращании к данной таблице. Т е нужно зарнее чётко решить для себя, какие данные являются сгруппироваными. Напрмире, UserID, password, NickName как правило нужны разом, например при входе в систему. Зачем тогда их держать вместе с информацией о стране и номером телефона. Впрочем, если такая потребность существует, то другой разговор. В общем, важно представить и понять какие этапы будет проходить юзер и что на этих этапах потребуется.
По поводу обмена сообщениями. Как вариант, но первое что пришло в голову:
создаём таблицы:
# Таблица хранения сообщений

CREATE TABLE messages (
int autoinkrement unique primary key not null msgid , // ID сообщения
datetime sendtime, // когда отправлено
text msg // сам текст сообщения
);

# таблица, которая отображает состояние сообщений

# CREATE TABLE msgspool(
int autoinkrement unique primary key not null msgid , // ID сообщения
int sentusr, // ID пользователя, что отправил
int resivedusr, // ID пользователя, что принимает
bool readed, // Читалось ли
datetime readedat, // Когда читалось
int prevoismsg // если у нас цепочка сообщений, то указатель на предыдущее
);

Считаю логичным разнести структуру на две таблицы, так как во второй возможны частые ALTER'ы, сигнализирующии о прочтении. эту таблицу лучше сделать InnoDB, а messages - MyISAM, т к там возможно будут часто проводить поиск. Впрочем возможно в подобной задаче это всё перегибы. Давно с SQL не возился ;)

PS
по поводу хранения фоток... тут верно подсказали с хранением ID и имени файла, добавлю только, что лучше хранить не имя файла, а некий относительный путь, и не хранить все фото в одном каталоге. Лучше установить некий лемит на их количество вот одной директории. Дело в том, что с увеличением их числа, скорость будет замедляться. Такое будет, даже на самых быстрых серверах. Если Вам нужен грамотный подход, ложите их в разные каталоги

большое спасибо за помощь и советы)

[QUOTE=Romik]Считаю что хранить информацияю в одной таблице не стоит, хотя бы потому, что вся информация не нужна всякий раз при обращании к данной таблице. [/QUOTE]

Можно разнести... Но зачем? Во-первых, вряд ли там будут сотни тысяч записей. Во-вторых, даже если все хранится в одной таблице это не сильно повлияет на скорость, а вот запросы станут сложнее и выполняться будут медленнее. К тому же кто тебе сказал что там БД будет MySQL?
Я считаю что парится с "оптимизацией" тут не стоит - не те объемы и не та нагрузка на сервер. Потому как если парится по-настоящему - тогда нельзя использовать MySQL.

2 RussianSpy
Человек попросил совета, как лучше и как правильно, вы же решили разъяснить как проще. Всё хорошо, да только раз говорим, то стоит говорить всё и объективно.
Если Вы считает что Ваш проект выйграет, отказавшись от реляционной модели, сэкономив на сложности запросов, то что ж, могу Вас только поздравить. Но выбор всегда должен быть осознаным. А для этого нужен обзор применяемых методов. Что, собственно, каждый из нас и попытался сделать - дать обзор. Полагаю господин Scottie сам сумеет принять нужное решение.

PS
По поводу MySQL Моё предположение весьма логично, ветка эта относиться к WEB программированию. Наиболее популярной СУБД для WEB, особенно среди начинающих web-программистов, является MySQL. Считаю бесполезным вести спор на эту тему, так как сие всего лишь отражает моё видение сложившейся ситуации, которое я ни в коем случае не навязываю. Что касается других СУБД, то думаю вполне реально применить полученую информацию на них, глядя на примеры для MySQL, применить как руководство, но не как конкретное решение.

Ну если ты хочешь чтобы все было "правильно", тогда ты сам указал неверный путь. Правильно - это абстрагироваться от типа БД и использовать классы вроде ADODB. Если проект будет расти, то переезд с недоБД MySQL на более серьезные вещи вроде PostgreSQL, Oracle или MS SQL пройдет что называется "в одно касание".

2 RussianSpy
Моё почтение, нельзя не признать, что абстрогирование от СУБД даёт плюсы при сопровождении и всяческих миграциях. Вы абсолютно правы. Кстати, а где я настаивал на использовании конкретной СУБД? Нельзя человеку рассказать о методах, неговоря ничего. Использовать примеры на конкретной СУБД очень даже наглядно. Ваше замечание по поводу ADO принимается, кстати это далеко не лучший способ ;) но достаточный, для решения ряда задач.
У меня к Вам только один вопрос, почему Вы провоцируете меня на спор там, где должно идти рассуждение и должны быть пояснения?

Нет. Просто люблю конструктивные дискуссии

не ожидал столь бурного обсуждения=) еще раз спасибо за советы...меня интересовало и интересует не конкретная задача с определенной СУБД и железом,а именно как все это правильно организуется,как,собственно говоря,заметил Romik.

а что касается MySQL,то я совсем недавно читал статью про один американский сервис,который создан без особых изысков и использует MySQL при огромном трафике,миллионной аудитории и сотнями регистраций в день.

[QUOTE=Scottie]а что касается MySQL,то я совсем недавно читал статью про один американский сервис,который создан без особых изысков и использует MySQL при огромном трафике,миллионной аудитории и сотнями регистраций в день.[/QUOTE]
MySQL не считается серьезной БД. И если создатели подобного сервиса использовали столь примитивную систему это не говорит ни в их пользу ни в пользу самой БД. Есть БД которые подходят для серьезных нагрузок: PostgreSQL, MS SQL и совсем мощные промышленные БД Oracle и IBM DB2. Почему так считается рассказывать не буду ибо очень много писать - на эту тему есть специализированные порталы например sql.ru
Для мелких проектов MySQL подходит вполне в силу того что она простая в использовании и настройке и не ест много оперативной памяти.
ЗЫ Надо будет провести экперимент по расчету статистики из таблицы объемом 68 миллионов записей