|
|
|
Области решений
|
|||
|---|---|---|---|
|
#18+
Допустим у меня есть ситуации и обстоятельства . Ситуация - узел, под которым в древовидной структуре, так сказать, сочетаются обстоятельства . Притом ситуация может сама входить как обстоятельство в некую другую ситуацию . Допустим каждая ситуация-обстоятельство связано с некими решениями . Задача состоит в том, что на вход "подается" структура связанных обстоятельств, которую надо "наложить" на имеющуюся сеть, в которой привязаны решения. По совпаденнии накладываемой сети с неким участком связанных обстоятельств идентифицируется соответсвующая им ситуация и таким образом находится решение . Можно ли это сделать средствами реляционной БД???? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2008, 07:11 |
|
||
|
Области решений
|
|||
|---|---|---|---|
|
#18+
Это вроде поиска по потенциально бесконечному ключу в котором не учитывается порядок полей. Хотя наверное и неудачная аналогия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2008, 07:14 |
|
||
|
Области решений
|
|||
|---|---|---|---|
|
#18+
Опичываемое вами ближе всего к графу. И деревья и графы можно реализовывать в РСУБД. Вы хотите получить от форума готовую схему БД для вашей задачи ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2008, 09:00 |
|
||
|
Области решений
|
|||
|---|---|---|---|
|
#18+
Программист-ЛюбительОпичываемое вами ближе всего к графу. И деревья и графы можно реализовывать в РСУБД. Вы хотите получить от форума готовую схему БД для вашей задачи ? Дело даже не в схеме. Навернео надо было помещать в разде Программирование, поскольку тут вопрос даже не схемы СУБД, а в целом - структура хранения + алгоритм. На другом форуме дали вариант. Ключевой момент - графы представляются как матрица. В ячейках -0 - если связи нет, 1 - если связь есть. Поиск вхождения подграфа в граф - перебор. Представляя граф как матрицу, легко переходим к схеме хранения - таблица, два поля. В каждом - номера вершин (Id обстоятельства-ситуации). Наличие записи говорит о наличии связи. Пограф - такой же набор. Опа - вот решение - два селекта - один с условием in, второй через not exists! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2008, 09:55 |
|
||
|
Области решений
|
|||
|---|---|---|---|
|
#18+
Но правда, решение дает далеко не каждое сочетание поэтому надо еще подумать над "нечеткой логикой" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2008, 10:44 |
|
||
|
Области решений
|
|||
|---|---|---|---|
|
#18+
что касается алгоритмов над графами, то кажется почти всё что можно уже придумали... и алгоритм на С++ будет в разы шутрее работать чем SQL конечно в некоторых ситуациях c SQL будет проще, но ИМХО в СУБД - хранить графы, а алгоритмы в клиентах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2008, 13:24 |
|
||
|
Области решений
|
|||
|---|---|---|---|
|
#18+
AlexsalogЭто вроде поиска по потенциально бесконечному ключу в котором не учитывается порядок полей. Хотя наверное и неудачная аналогия. Угм. Я такое делал. Гарантировано работало, только при прокладке "маршрута" с самого верха. Решения для случаев: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. так не было найдено. Решили, что, раз есть два N3, то без разницы, в который из них добавлять новые данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2008, 10:52 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35505528&tid=1543677]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
283ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 584ms |

| 0 / 0 |
