Другой разговор, что вторым параметром должно быть целое число, ну так в php срабатывает приведение типов если я правильно понял. То есть строка "pass" преобразуется в число 0, другими словами везде вторым аргументом передается ноль, поэтому и работает.
Вы обращали внимание, как вконтакте организован доступ к контенту?
Примерно так vk.com/content{user_id}_{content_id}
Сообщение №574 от пользователя 23 будет иметь вид vk.com/message23_574
А фото 432 от пользователя 33 - vk.com/photo33_432
Это не точные ссылки, здесь показан принцип!
Я хочу сделать подобную структуру в MySQL и рассматриваю плюсы и минусы.
При этом структура таблицы `messages` будет иметь приблизительно такую структуру:
Из плюсов мы видим улучшенную индексацию (сразу по 2м полям), выборка будет явно быстрее.
А что касается минусов - то тут усложняется процесс выборки, вместо одного поля приходится указывать два.
А теперь, собственно вопрос - как сделать, чтобы при вставке user_id у меня автоматически инкрементом вставлялся message_id??
И вообще, что думаете о такой структуре? (Добавление)
P.S. понятно, что в итоге вместо user_id надо использовать user_from и user_to, но я не стал усложнять, это всего лишь пример
Спасибо за отзывы и советы, обязательно все учту. Хотелось бы услышать комментарии людей, имеющих опыт в создании чего-то подобного с большой нагрузкой.
Всем привет! Заголовок многообещающий, но на деле вопросы простые. Их два.
1) Как бы вы организовали хранение личной инфы о пользователе? В одной таблице или же в нескольких?
Ситуация в том, что полей может быть очень много
логин
пароль
емаил
телефон
страна
город
пол
возраст
скайп
аська
рост
вес
дети
отношение к курению
...
Рассматриваю два варианта:
Одна таблица. Плюсы: простота выборки. Минусы: большая нагрузка на сервер. Если пользователей ~N млн., а нам надо выбрать только тех, кто online, вычитая из текущей даты дату последного клика, то при такой структуре будут тормоза ого-го.
Две и более таблиц. Плюсы: при малом количестве полей небольшая нагрузка. Минусы: сложные связи между таблицами, множественные.
Что посоветуете?
И вопрос №2, посложнее.
2) Как бы вы организовали хранение фотографий на сервере?
На эту тему есть множествостатей. Пока склоняюсь к варианту с хабра, когда путь вычисляется по айди.
На многих сайтах используют несколько серверов для изображений. Где про это можно почитать? На данный момент смотрю в сторону WebDAV.
Вариант с хранением изображений в БД не рассматриваю.
Math.random() позволяет сделать каждый раз ссылку на капчу уникальной. Значит она не будет кешироваться браузерами. Вы попробуйте, тут понимать не обязательно.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 352
