"Динамичные битовые маски"

← →
{RASkov} © (2008-01-10 02:02) [0]

Подскажите пожалуйста алгоритм реализации вот какой задачи:

Есть некая структура, для удобства возмем две таблицы БД.
Собственно в конечном варианте возможно(скорее всего) БД и останется
Пример с таблицами:

1я и 2я таблица должны содержать по одному основному полю("Название"), остальные "внутренние"(служебные)....
Я в БД плохо ореентируюсь, да и то только если примитивный БДЕ, поэтому если что, то "сорь" с БД терминами...

Струтура, в моем понятии, нечто такая:
1 Таблица:
----------------------------------
ID - номер записи
Title - "Название записи"(сумбурно)
CODE - собственно код характеристик (См. ниже 2 таблицу)
Х - может
Х - и
... для чего-то по этому вопросу нужные поля...
----------------------------------
2 Таблица:
----------------------------------
ID - номер записи(уникальный код записи, например автоинкремент);
NameCharacteristic - название характеристики записи из первой таблицы.
Х - может
Х - и
... для чего-то по этому вопросу нужные поля...
----------------------------------

Как эта структура работает? Объяснить не могу(незнаю), но вот для чего, и как я вижу альтернативное решение:

В первую таблицу "набиваются" записи, например названия книг.
Во второй должны быть характеристики книг (жанры, авторы.... еще чего-то)... таблица набивается паралельно с первой...
Например занесли в первую таблицу книгу с новым жанром, (т.е. с таким жанром еще не было) и паралельно добавили жанр во вторую...

Как я "видел" реализацию: ...Битовые маски и ограниченные(статичные) записи во второй таблице(кол-во характеристик 32 - Integer(32бита)), но хотелось бы именно динамично менять вторую таблицу(имея при этом более 32 записей), причем чтоб при изменениях не нарушалась "связь"....
Записи("Названия") могут редактироваться и в первой и во второй таблицах....
При удалении характеристики(думаю отдельный случай, и тут нужна некая переиндексация чтоли)

Далее в программе будет реализация некоего фильтра:
Изначально отображены все записи первой таблицы. Выбрали во второй например жанр - Стихти - в первой отфильтровались только те записи у которых в CODE "есть код записи"(Стихи) из второй.... и так далее....

Выглядеть в программе будет типа так: при каждом последующем выборе характеристики, будет строиться некий путь характеристик, любое звено которого можно будет исключить из пути, путем удаления из фильтра кода...

FILTRCODE:=FILTRCODE or ID(2 таблица); - добавление
FILTRCODE:=FILTRCODE and not ID(2 таблица); - удаление

Фильтр = CODE(1 таблица) and FILTRCODE = FILTRCODE

Вот собственно все расписал, если что могу дополнить :) Надеюсь было понятно все...
Какие есть предложения по данному вопросу? Вот я наворотил :) Спасибо тому кто осилил это прочитать)

← →
{RASkov} © (2008-01-10 02:15) [1]

Т.е вопрос именно в алгоритме организации данной схемы фильтра данных...
Пример с книгами - просто пример.... могут быть любые данные...
И не хотелось бы ограничений, на кол-во записей во второй таблице...

Все что я расписал в [0], как я вижу реализацию алгоритма - может быть не верно....
Хотелось бы оптимального, нормального, стабильного решения.... А может оно не так все сложно как мне кажется?
Еще раз Спасибо за внимание.

← →
Германн © (2008-01-10 02:18) [2]

> {RASkov} © (10.01.08 02:02)

> Как я "видел" реализацию: ...Битовые маски и ограниченные(статичные)
> записи

Т.е. множества ты не знаешь? Или знаешь только Паскалевские множества?
Оператор IN в SQL тебе знаком?

← →
Anatoly Podgoretsky © (2008-01-10 02:24) [3]

А база наверно секретом является. Битовые операции есть в MS SQL и вроде в Оракле, но не советую с этим связывать, проблем будет много.

← →
Германн © (2008-01-10 02:39) [4]

> Anatoly Podgoretsky © (10.01.08 02:24) [3]

Толь. Да не нужны ему "битовые операции".
Его просто нужно отучить использовать фильтр в TTable, а взамен познакомить его с SQL. Он свой, Он поймёт.

← →
{RASkov} © (2008-01-10 02:40) [5]

> [2] Германн © (10.01.08 02:18)
> Оператор IN в SQL тебе знаком?

:(
Я же предупредил про БД... Я в БД как казел в ананасах... знаю примитивную работу с TTable и БДЕ (

> Т.е. множества ты не знаешь?

Знаю.... Но как будет выглядеть это? Я думал об них...

← →
{RASkov} © (2008-01-10 02:41) [6]

> [3] Anatoly Podgoretsky © (10.01.08 02:24)
> А база наверно секретом является.

Да нет некиких секретов.... я БД предложил как вариант, поэтому... если есть предложения, то я не против...

← →
{RASkov} © (2008-01-10 02:43) [7]

> [4] Германн © (10.01.08 02:39)
> Его просто нужно отучить использовать фильтр в TTable, а
> взамен познакомить его с SQL. Он свой, Он поймёт.

Вот это мне нравится :)
Только боюсь, не справлюсь :(
Очень збивает с мысли мои теперешние понятия о БД, построенные в свое время методом тыка изучения БД с использованием TTable и БДЕ.....(

← →
Германн © (2008-01-10 02:43) [8]

> {RASkov} © (10.01.08 02:40) [5]

Ну так учи SQL. На первый раз поможет справка по LocalSQL.

← →
{RASkov} © (2008-01-10 02:55) [9]

> [8] Германн © (10.01.08 02:43)
> Ну так учи SQL.

Ну попробую еще в очередной раз :)
Пытался уже сколько раз...(

Спасибо за подсказку в сторону БД...
А без SQL (с использованием примитивных таблиц, фильтра и "супер пупер" алгоритма) - нет решения? (с надеждой легкого пути) :)
Записей в первой таблице не думаю, что будет много.... даже очень мало.... менее полтыщи....

← →
Anatoly Podgoretsky © (2008-01-10 03:00) [10]

> {RASkov} (10.01.2008 02:40:05) [5]

Вот пока Козел, и есть возможность исправиться.
Сразу возьми за правило, никаких Table и никаких TAdoQuery, не придется потом себя пересиливать.
Дальше надо немного теорию посмотреть и потом конкретный диалект языка.
Простые запросы все в состоянии освоить.

← →
{RASkov} © (2008-01-10 03:01) [11]

> [8] Германн © (10.01.08 02:43)

А даже с SQL"ем - как?

т.е. как в первой таблице хранить "связь" со второй.....
Я же могу одной какой-нибудь записи из первой таблици, проставить все имееющиеся характеристики из второй...
Или это в SQL"е - "не вопрос"?
А в дольнейшем отредактировать и убрать половину характеристик, например.
??

← →
Германн © (2008-01-10 03:05) [12]

> А без SQL (с использованием примитивных таблиц

Здравствуй Парадокс!
Решение я, конечно могу подсказать.
Но я не знаю твою весовую категорию :)

На том же примере с книгами.

Каждая книга может относиться к нескольким жанрам одновременно. И к каждому жанру может относиться несколько книг. Значит, здесь нужна связка "многие ко многим". Обычный способ реализации такой связки - с помощью вспомогательной таблицы. В итоге имеем следующую структуру БД:

Таблица 1 (жанры):
ID - целое (можно автоинкрементное), первичный ключ;
Название жанра - строка, not-null, уникально;
... // и любые другие.

Таблица 2 (книги):
ID - целое (можно автоинкрементное), первичный ключ;
Название книги - строка, not-null, уникально;
.... // и любые другие.

Таблица 3 (реализует связь "многие ко многим"):
ID жанра - ссылка на таблицу 1, not-null, первая часть первичного ключа;
ID книги - ссылка на таблицу 2, not-null, вторая часть первичного ключа.

Вот и все. По желанию можно сделать каскадное удаление записей из таблицы 3 при удалении записей из таблиц 1 и 2 (а можно и не делать, а просто запретить некорректное удаление).

> Таблица 1 (жанры):
> ID - целое (можно автоинкрементное), первичный ключ;
> Название жанра - строка, not-null, уникально;
> ... // и любые другие.
>
> Таблица 2 (книги):
> ID - целое (можно автоинкрементное), первичный ключ;
> Название книги - строка, not-null, уникально;
> .... // и любые другие.
>
> Таблица 3 (реализует связь "многие ко многим"):
> ID жанра - ссылка на таблицу 1, not-null, первая часть
> первичного ключа;
> ID книги - ссылка на таблицу 2, not-null, вторая часть
> первичного ключа.

Вот здесь буду спорить.
Таблица1
ID - в справочной таблице автоинкрементным делать , ИМХО, крайне нежелательно. Как минимум инкримент можно и средствами SQL организовать (что-то типа Select ID=IsNull(Max(ID)+1, 1) from Table)
Тоже самое касается и Таблицы 2 (как ни крути, она тоже справочная).

Далее, в обе справочные таблицы добавил бы поле SortOrd int not null default 0
Это для Order By SorOrd, Name. (часто юзвери просят сделать возможность самостоятельной сортировки справочных таблиц, типа, наиболее часто встречающиеся поля - наверху выборки)

Ну и наконец Таблица 3 - не надо делать составного первичного ключа. Поставьте рядом как раз автоинкрементный счётчик, объявите его первичным ключом, а оставшиеся 2 поля - вторичные ключи к своим справочникам + если есть сильное желание, на них в паре можно уникальный индекс наложить.
Это к вопросу о суррогатных первичных ключах.

> Ega23 © (10.01.08 10:05) [15]

Олег, хорошо хоть то, что против самой схемы ты не возражаешь. Которую, собственно, я и хотел показать - и лишь ее, причем как можно проще, чтобы не запудривать тонкостями мозги человеку, который в БД, по его собственным словам, пока не шарит.

А ты ему об индексах... думай, голова...

> хорошо хоть то, что против самой схемы ты не возражаешь

Ещё бы я на основы руку поднял... :)

> нужна связка "многие ко многим".

Спасибо всем. Значит БД и эта связка....

"Динамичные битовые маски" Найти похожие ветки