|
|
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
таблица: m_frend дружит со sl_frend (в примере 883 дружит с 876), НО есть записи в которых другие uid`ы дружат с m_frend (то есть в таком случае m_frend будет sl_frend`ом). Пример 856 дружит с 883. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Нужно в одном запросе, ОДНИМ СТОЛБИКОМ, вытянуть всех друзей 883 (тех с кем дружит 883), и ТЕХ КТО ДРУЖИТ С 883. Такой вот калмбурчик вышел, надеюсь проблему описал понятно. И реально ли это сделать (получить результат в одном столбце)? - - - Знаю что можно сначала получить Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. а потом в коде отбросить 883. но как результат запроса получить одним столбцом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2016, 20:01 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
aliskin, union спасёт отца русской демократии ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2016, 20:02 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
как все просто. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2016, 20:44 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
я так понял что столбЦЫ переименовываются по AS, а дальше понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2016, 20:46 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
А так? SELECT (m_frend + sl_frend - 883) AS frend_id FROM frends WHERE m_frend = 883 OR sl_frend = 883; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 11:01 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 11:16 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
Тоже красиво. Но как понимаю, без where придется шерстить всю таблицу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 11:29 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
А её так и так шерстить всю, если нет нужных индексов - но в моём варианте один раз, а не два. А если они есть, то имхо самый быстрый по выполнению вариант - это UNION ( 19297411 ). Да и вариант Код: sql 1. 2. 3. 4. 5. 6. 7. тоже не самый неудачный будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 11:39 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
Ну у меня вроде то же самое написано (дистинкт только добавить). А почему юнион быстрее? Все же 2 селекта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 11:47 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
paverпочему юнион быстрее?Если есть ДВА индекса - по m_frend и по sl_frend,- и у них высокая селективность, то в случае UNION для каждого подзапроса будет использоваться наиболее подходящий индекс (а если они покрывающие - вообще сказка). А для остальных - максимум один из них, а если они не покрывающие, что скорее всего во всех остальных случаях будет fullscan. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 11:50 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
paverу меня вроде то же самое написано (дистинкт только добавить) ихде? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 11:51 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
Вот жеж 19303982 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 11:55 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
Ааа... это я пропустил - код не в теге не воспринимается как код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 12:07 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
мне написали на одном ихз форумов автор Тут с одной стороны все понятно с UNION. Но посмотрите немного глубже. Структура таблиц не соответсвует принципам реляционных баз данных. Чем у Вас левый товарищ может отличаеться от правого? Они же совершенно равноправны. Тут лучше использовать такую структуру Люди (ИД) Отношение товарищества (ИД) Товарищи (ИД_Отношения_товарищества, ИД_Человека) Конечно, тут придется использовать цже не UNION, а JOIN. а вы как считаете? Мой ответ: автор НЕЕТ! Это таблица дружественных отношений. ВСЯ ДРУЖБА уже абсоолютно верно обраабатывается и вывод кнопок в профиле тоже уже железно написан. Все так как должно быть.. Отличия в том что левый товарищ первым подает заявку в друзья второму (правому товарищу.) --- Откуда люди столько знают о мСэКюэЛе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 13:08 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
Откуда люди столько знают о мСэКюэЛе? --- это моя мысля.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 13:09 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
aliskin а вы как считаете? А мы не в курсе. Если то, что "А друг Б", означает автоматически, что "Б друг А", то что-то осмысленное (но именно что-то) в возмущениях имеется. А если нет - то это бред голимый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 13:20 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
Akinaaliskin а вы как считаете? А мы не в курсе. Если то, что "А друг Б", означает автоматически, что "Б друг А", то что-то осмысленное (но именно что-то) в возмущениях имеется. А если нет - то это бред голимый. да А = Б, но повторяюсь: авторОтличия в том что левый товарищ первым подает заявку в друзья второму (правому товарищу.) --- Кроме этого у мення есть таблица из ДВУХ полей. в ОБЕИХ полях ИД пользователей, но в этой тбл левый ИД означает что он заблокировал правый ИД. Не хотел и дружбу и блокировку писать в одну тбл, поэтому и разделил на две. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 13:27 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
да А = Б и Б = А, но ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 13:28 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
авторОтличия в том что левый товарищ первым подает заявку в друзья второму (правому товарищу.)А вот теперь смотри. У тебя начальное состояние - "А и Б не друзья". Конечное состояние "А и Б друзья". А ОДИНАКОВОМУ начальному и конечному состояниям могут соответствовать РАЗНЫЕ данные. Вот именно это и неправильно. Недетерминированность. Поэтому правильной структурой в случае, если дружба симметрична, а порядок её установления незначим, с точки зрения нормализации будет (ИД юзера - ИД дружеских отношений). С ограничением COUNT(ИД дружеских отношений) = 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 13:33 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
Что значит "У тебя начальное состояние - "А и Б не друзья". Конечное состояние "А и Б друзья"."? Дружба обрвбатыввается так(без кода но словами поясню): Если записей в тбл блокировки нет, то идет обработка дружбы. Если есть записи в тбл блокировки (блэклист) то предпринимаются неките действия (например показ вообщ: полльзов заблокирован ВАМИ или Вы заблокированы пользователем.), Обработка дружбы не просходит. Какой смысл узнавать статус дружбы если ее нет? Обработка дружбы: Если ТОТ пользователь (тут важно не путать пользователей: Поэтому ТОТ пользов - это будет пользователь профиль которого СМОТРИМ. А тот КТО смотрит - будем называть "Я"). Так воот: Если ТОТ пользователь незаблокирован и МЕНЯ он не заблокировап, И УЖЕ подал заявку в друзя, то при подтверждении МОЕЙ дружбы с ТЕМ пользователем или при подаче МНОЙ заявки в друзья - статус дружбы установить 1 (то есть друзья). --- Если ТОТ пользов не друг и не заблокирован - то добавить запись в тбл и поставить статус дружбы 2 (Я подал заявку и ожидаю дружбы). --- Нуезнаю поняли ли вы мое написание, НО Смысл в тот, в тбл дружбы НИКОГДА не будет Код: sql 1. 2. 3. ну и + к этому проверки чтобы уже заблокированные не смогли дружить без разблокировки. ПОЧЕМУ так: Потому что например вы сегодняч созранили страницу профиля пользователя у себя на копме. там есть книппки "добавить в друзья". завтра этот пользоватлеь вас аблокирует но ы вдруг захотите попробовать подаь ему заявку в друзья с сохраненной страницы. вот такиее ввсякме проверки у меня уже реилизованы. Потому и оговорю что дружба уже написана абсолютно железно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 13:58 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
[quot Akina]автор...Поэтому правильной структурой в случае, если дружба симметрична, а порядок её установления незначим, с точки зрения нормализации будет (ИД юзера - ИД дружеских отношений). С ограничением COUNT(ИД дружеских отношений) = 2. Порядок установки важен. Ну и как я смогу знать с кем дружит этот ИД, если вы написали что нужно ИД юзера и ИД дружОтношений? Все равно нужно связать ДВА ид пользователЕЙ (+ статус дружбы который их связывает). Я выше уже хоть как-то написал о том что и как у меня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 14:04 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
aliskinЧто значит "У тебя начальное состояние - "А и Б не друзья". Конечное состояние "А и Б друзья"."?Я выбираю два момента времени. Первый - А и Б ещё не друзья, никаких заявок на дружбу меж собой не подавали. Соответственно в этот момент времени в твоей таблице НЕТ записи с их идентификаторами. Второй - А и Б уже друзья, заявка подана, и она принята. С точки зрения детерминированности состояние БД должно быть однозначным. Но у тебя имеется два равновероятных состояния базы данных. Это и есть неправильность. Соответствие между состоянием системы и состоянием базы данных, хранящей сведения об этом состоянии, должно быть однозначным в обоих направлениях. Однако твои последние пояснения говорят о том, что информация, кто кому подал заявку, на самом деле является значимым атрибутом дружбы. То есть второй момент времени может иметь два разных состояния: "А и Б друзья, причём заявку подал А" и "А и Б друзья, причём заявку подал Б". Каждому этому состоянию соответствует строго одно состояние базы данных. С точки зрения нормализации всё в порядке, и твоя структура - правильная. А то, что ты принял решение хранить сведения о том, кто подал заявку, именно таким способом - ну это дело твоё, имеешь право. Не очень удобно, зато лаконично и легко понимаемо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 14:12 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
:) ага, а также огромный плюсище в легкости обработки статусов дружбы и вывод нужных кнопок в профиле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 14:17 |
|
||
|
Простой-сложный select
|
|||
|---|---|---|---|
|
#18+
AkinaЭто и есть неправильность. Соответствие между состоянием системы и состоянием базы данных, хранящей сведения об этом состоянии, должно быть однозначным в обоих направлениях. Ну ведь у меня даже поля нажываються m(ain)_frend и sl(ave)_frend не просто так. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2016, 14:24 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39257605&tid=1831658]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
154ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 438ms |

| 0 / 0 |
