Проектирование баз данных: Лучшая структура таблицы для получения отношений Пользователя/Друга?
Проблема с сравнениями заключается в том, что их трудно отлаживать, когда вы помещаете >=, где должен быть <=
# v---------- should be <
if number >= 10000 and number >= 30000:
print ("you have to pay 5% taxes")
Python позволяет вам просто писать , что вы подразумеваете под словами
if number in xrange(10000, 30001): # ok you have to remember 30000 + 1 here :)
В Python3 вам нужно использовать range вместо xrange.
edit: Люди, похоже, больше озабочены микробизнесом отмечает и как классные операции цепочки. Мой ответ - о защитном (менее атакующем для ошибок) программировании.
В результате претензии в комментариях я добавил здесь микро-тест для Python3.5.2
$ python3.5 -m timeit "5 in range(10000, 30000)"
1000000 loops, best of 3: 0.266 usec per loop
$ python3.5 -m timeit "10000 <= 5 < 30000"
10000000 loops, best of 3: 0.0327 usec per loop
Если вас беспокоит производительность, вы можете вычислить диапазон один раз
$ python3.5 -m timeit -s "R=range(10000, 30000)" "5 in R"
10000000 loops, best of 3: 0.0551 usec per loop
7 ответов
UserRelationship
====
RelatingUserID
RelatedUserID
Type[friend, block, etc]
Соглашаются, что взаимность не принадлежит как столбец; нормализация повреждений.
Я сделал бы что-то подобное тому, что Вы имеете, но удаляете флаг "IsMutual". Просто добавьте вторую строку с обратными значениями, когда это будет взаимно. Это действительно добавляет строки, но чувствует себя намного более чистым.
Я в настоящее время создаю сайт социальной сети для клиента, и я выразил вещи этот путь
CREATE TABLE [dbo].[PersonFriend] (
[Id] INT IDENTITY (1, 1) NOT NULL,
[Timestamp] DATETIME NOT NULL,
[ChangeUser] NVARCHAR (200) NOT NULL,
[FriendStatusId] TINYINT NOT NULL,
[Person1Id] INT NOT NULL,
[Person2Id] INT NOT NULL,
[Person1RequestTimestamp] DATETIME NOT NULL,
[Person2AcknowledgeTimestamp] DATETIME NULL
);
, Каждый человек хранится в таблице Person (вообразите это). Полями Person1Id и Person2Id является FK к таблице человека. Я сохраняю список состояния в таблице FriendStatus для покрытия, было ли что-то запросом, принятым, отклоненным, проигнорированным и т.д., поле Timestamp является стандартным в моем дизайне для указания на рекордное создание (это - вещь шаблона, которая используется в основным классом персистентности), и его отчасти дублированный в этой таблице, поскольку Person1RequestTimestamp содержит те же данные. Я также получаю, когда Person2 видел запрос и сделал действие (который обозначается в FriendStatusId) на нем, и сохраните это в Person2AcknowledgeTimestamp).
Одно из базовых предположений об этом дизайне может быть указано это, Person1 запросил дружбу Person2 - если та дружба принята затем, дружбу считают взаимной.
Возможно, добавьте таблицу Relationship, поместите свойства отношений там и сошлитесь на нее от UserFriend.
Вероятно, чрезмерно, но можно использовать семантическую паутину для моделирования этого. Можно использовать FOAF (Друг FOAF Друга) - формат.
Вам на самом деле нужна физическая таблица, чтобы обнаружить, существуют ли общие друзья? Почему бы не SQL-запрос как:
SELECT U.ID, U.NAME FROM USER U
INNER JOIN USERFRIEND UF
ON U.ID = UF.FRIENDID
WHERE U.ID = (SELECT USER.ID FROM USER
WHERE USER.ID = friend_id AND USER.ID != your_id);
Результаты запроса должны возвратить всех общих друзей.
Дружба менее ясна, чем классические сценарии самосоединения работодателя/босса и пользователя/супруга. Действительно ли дружба является отношениями или действием? Я получил изрядное количество критики за пренебрежение последнего. Так или иначе Вы, вероятно, испытываете необходимость больше чем в одной таблице, неважно, насколько универсальный Ваша модель данных.