Меню
Что нового?

ID записи ноль или -1?

ну разное много что делать придется в любом случае. или предлагаешь чтобы любой гость мог редактировать общий гостевой профайл, например? :) на общем фоне небольшая разница, тем более, Guest вполне может это реализовывать прозрачно.
 
что не так?
Нажмите для раскрытия...
^^^^^^^ я написал в 1 и 2, что не так :-) + я говорил о PK, а не FK

-~{}~ 20.06.10 23:21:

ну разное много что делать придется в любом случае. или предлагаешь чтобы любой гость мог редактировать общий гостевой профайл, например?
Нажмите для раскрытия...
эм. есть ACL, который проверяет может ли конкретный пользователь редактировать конкретный профиль:
а) обычные юзера могут править только свои
б) админы могут править всех
в) гости не могут править никого
 
а не слишком ли много заглушек для гостя получится в базе? возьмем например профайл фейсбука :D

хотя так-то тоже вариант. но надо еще помнить о том, что будем делать при удалении пользователя. с left join ничего страшного, а вот update comments set user_id=0 where user_id=22222 это трындец базе.
 
возьмём. какие там "заглушки" для гостя получатся, кроме 1 такой же записи?

а зачем нам пользователей удалять??? если юзер хочет навсегда уничтожить о себе инфу - тогда помечаем его как deleted и перезаписываем его инфу пустышками.
в том же фейсбуке как раз 2 вида удаления есть: с возможностью восстановления и без оной.

но, согласен, в этом случае нам придётся обрабатывать этот флажок deleted в выборках (поиск по людям) и в отображении, но вот в твоём варианте наряду с магическим значением NULL, которое обозначает гостя, придётся вводить какое-то ещё, обозначающее "пользователь удалён"
 
1
хрен с ним с фейсбуком - в принципе и правда 1 =)

2
почему?
left join on (user.id = t.user_id and user.deleted=0)
 
Код: 
template1=# alter table users add column deleted boolean default false;
ALTER TABLE
template1=# insert into users (id) values (1),(2);
INSERT 0 2
template1=# insert into comments values (1,1),(2,2),(3,1);
INSERT 0 3
template1=# update users set deleted=true where id=2;
UPDATE 1
template1=# select comments.id, users.id from comments left join users on(users.id=comments.user_id and users.deleted=false);
 id | id 
----+----
  1 |  1
  2 |  (null)
  3 |  1
(3 rows)
 
я не понял в том смысле - что как это относится к беседе? :-) всё равно придётся в отображении делать исключения.
более того - ты в этом случае не узнаешь, гость это или удалённый пользователь.
 
Дык в любом случае придется. Узнать если надо тоже ничто не мешает, просто запрос будет другой.

В общем, мне не очень понятно, зачем пляски с magic numbers, если все спокойно укладывается в 3НФ. Ради выбора ника "гость"? Если теперь учесть вариант с многоязычностью, то вообще смысл пропадает.
 
Ну вообще - не пропадает. Модель сама может отдавать нужное имя пользователя, в зависимости от текущего языка.

Узнать если надо тоже ничто не мешает, просто запрос будет другой.
Нажмите для раскрытия...
запрос будет сложнее.
да и оба решения не нарушают нормальности.

кароче и тут как в теме про эксепшны - пис. я делаю так, у меня есть причины так делать, и их я озвучил :-)
 
То есть в модели появлятся многоязычность для ника ради одного единственного "гостя"? Или всем пользователям предлагается ввести их ники на всех языках? гггг

Ваще да, на самом деле есть причины и так делать. У меня на эту тему баттхерт после инвиженборда, который запросами set user_id=0 where user_id=222 клал всю базу нахрен =) хотя он то вообще весь целиком через жопу сделан.
 
а в модели так и так многоязычность должна появиться. мультиязычность интерфейса - это полумера. даёшь мультиязычность и контента :-)
 
Войдите или зарегистрируйтесь для ответа.
Сверху