Форум MySQL

Привидите пожалуйста примеры запросов, добавления и выборки данных с полями типа SET.

Как добавлять денные?
Как брать?
И как делать выборку по ним?

Раньше никогда не применял такие поля, а сейас возникла потребность, но че-то не везжаю как жто сделать. Ведь при добавлении нескольких SETов это же как несколько строк, а хронятся они все в одном поле.

У меня каталог статей, с бесконечной вложенностью. Корневые группы: Публикации, Новости, Номенклатура.

В разделе Публикации, еще много подргуп, и под-подгрупп. Сейчас надо сделать, на главной странице, чтобы выводилось 5 последних публикаций. А в др. блоке, 5 последних новостей. Вот я и думаю, что проще всего будет добавить в таблицу со статьсями поле SET('art','news') чтобы по нему делать выборку.

Я проавильно вообще все это думаю? или можно как-то по другому сделать, более эффективно?

Выбор типа SET('art','news') подразумевает, что каждая из статей может быть объявлена
а) публикацией
б) новостью
в) сущностью, которая является как публикацией, так и новостью
г) сущностью, которая не является ни публикацией, ни новостью
а также д) её сущность может быть неизвестна (если поле допускает NULL)

Вы именно такого представления добиваетесь?
Или может быть Вам нужен enum?

>Выбор типа SET('art','news') подразумевает, что каждая из статей может быть объявлена
>а) публикацией
>б) новостью
>в) сущностью, которая является как публикацией, так и новостью
>г) сущностью, которая не является ни публикацией, ни новостью
>а также д) её сущность может быть неизвестна (если поле допускает NULL)

Да, именно так.

INSERT INTO tbl (kind) VALUES ('art,news'); UPDATE tbl SET kind = 'art,news' WHERE kind <> 'art,news'; SELECT kind FROM tbl WHERE FIND_IN_SET('news',kind)>0;

А естли kind такое: SET('art','news','n1','n2','n3'). Как выбрать записи, в у которых, например, есть 'art' и 'n2' ?

И еще вопрос. Когда я извлекаю всю строку, то переменная kind будет иметь значение 'art,news'? Т.е. строку значений, разделенную запятыми. Так? И чтобы мне по этим значениям например заполнить флажки формы, мне его надо будет разбирать дополнительно функцией explode?

очевидно, так.

В принципе,с битовыми полями знаком давно,но как это реализуется в MySQL ? С выборкой я разобрался,а вот по вставке...К примеру,имеем поле field типа SET('b0','b1'...'b7') и я делаю вставку field='b0,b2' .Вопрос:после вставки неуказанные биты не затронутся или будут сброшены в ноль ? Если сброшены,то как установить/сбросить отдельные биты,не затрагивая остальных,то есть выполнить подобие операций AND 01011111 или OR 10100000 ???

Я полагаю, следует использовать побитовые операции (& | ^ ~ << )? приведение типов, а также функции EXPORT_SET и FIND_IN_SET

Лично я предпочитаю поля BLOВ (или для коротких множеств - INT, BIGINT) и операции с битами, реализованные руками.

Хреново...Я то надеялся,что поле SET подобно строке таблицы,то есть необязательно знать порядок расположения битов/столбцов в поле/строке,достаточно знать их имена...А вводить 64 столбца в таблицу,чтобы заполнять их значениями 0 и 1-это......

Или может,я коряво организовал алгоритм и кто-то предложит что то умнее ? Смысл таков:имеем множество разделов сайта,в каждом из которых может быть несколько модераторов или суперюзеров.Имеем множество людей,которые могут быть модерами/суперюзерами в нескольких разделах сайта.Я реализовал так:таблица profile ,поля login,pass, ... xsuperuser SET('gb','forum1',...) и аналогичное xmoderator.

>Хреново...Я то надеялся,что поле SET подобно строке таблицы,то есть необязательно знать порядок расположения битов/столбцов в поле/строке,достаточно знать их имена...
Так и есть.

>А вводить 64 столбца в таблицу,чтобы заполнять их значениями 0 и 1-это......
Я такое предлагал?!
Плотность хранения информации в обоих случаях максимальная - 1 бит на 1 элемент множества.

Извините,забыл в первом предложений добавить "...достаточно знать их имена и произвольно изменять биты/поля,не затрагивая других битов/полей в поле SET/таблице".В этом и вся беда,что,как я понял,изменения идут только по всем битам одновременно.В общем,надо или правда смотреть в сторону другого типа поля,или менять алгоритм,или вытаскивать все значения из поля,текстовыми функциями искать/вырезать/вставлять и записывать поле обратно :-(((

Вот недавно тов. Trianon Указал по поводу этой темы,что я просто "не сумел довести реализацию до ума..." Все уже решено через тип поля TEXT и строковые функции,но все же стало интересно,в натуре я такой тупой :) и возможно ли как либо реализовать мой алгоритм более рационально...Мне это очень интересно,так как не стыдно учиться,стыдно не учиться,а мне ужо 31 год,может,я просто потерял нюх к новым решениям,закостенел ??? Кто сможет понять,о чем речь в моей теме,прошу настоятельно ответить

Просто я начал программировать в эпоху 3.5 мегагерцевых процессоров,когда в 40 кб озу вмещалась хорошая трехмерная игра,а в 4 кб я записывал 300 строк с 8-10 символьным именем,размером и кучей другой инфы,и мне просто дико битовую информацию писать в отдельное поле...

Что-то я не очень понял Ваш взрыв...
Вы хотите знать, как хранить множества в виде битовых полей и произвольно манипулировать ими?
Или Вы хотите хранить множества в типе SET языка MySQL и иметь возможность быстро и прямо выводить результат?
Или Вы хотите и то и другое сразу?

Последнее я не обещал.
Второе Вы, как я понял, изучили досконально сами, и остались недовольны. Я, кстати, тоже.
А первое могу показать.

К слову сказать, я учился программировать на ЭВМ второго поколения. Сейчас такие в музеях не сыщешь.

1. Как манипулировать битовыми полями,я знаю,и надеялся,что в бд это организовано получше... :( просто я естественно могу быть неправ,и ессно хочу узнать,как лучшей и небольней организовать моя алгоритм :) 2. Для себя-что есть компьютер 2-го поколения ?

Зал метров 50 квадратных.. со шкафами
Например 3 шкафа - процессор, еще пара шкафов - 2 блока ОЗУ по 4 килослова (каждое слово по 37 бит) и т.д.
Интеграция уровня отдельных транзисторов, диодов, сопротивлений, конденсаторов .

А да,вспомнил:1-лампы,2-транзисторы,3-БИС,4-микропроцессоры...Что ж,тогда вы должны знать цену каждого бита информации ...

А я её знаю.

Только это не умаляет того факта, что в реляционных БД разные элементы одного типа нужно хранить на разных строках, если есть нужда работать с ними независимо.
В противном случае схема БД вылезает из 1-й , 2-й, 3-й нормальных форм, и оперировать ей становится сущее мучение.