Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / БД с заранее не известным числом полей / 25 сообщений из 25, страница 1 из 1
20.01.2014, 13:28
    #38531736
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
Задача : БД поверхностей (плоских), каждая из которых определяется списком вершин (их может быть от, очевидно, 3 до ...)

Попытка решения : сделать таблицу с вершинами и поверхностями примерно так:
Код: plaintext
1.
2.
3.
4.
5.
Vertexes    Surfaces
   uid         uid
   x           v1
   y           v2
   z           ...
               v15
(т.е. прописать некоторое количество вершин заранее), но тогда ограничится число вершин, а если (вдруг?) необходимо будет записать поверхность с более, чем 15ью вершинами? Да и нехорошо это - плодить поля "про запас", насколько мне думается...
К тому же, если из поверхностей в последствие собирать некоторые объемные тела, то вопрос там будет ставиться аналогично, и если здесь я могу относительно безболезненно жестко ограничить число вершин (скажем, 6-8-10...), то там уж точно не предугадать.

Попытка решения альтернативная : сделать таблицу с вершинами и поверхностями по-другому:
Код: plaintext
1.
2.
3.
4.
Vertexes    Surfaces
   uid         uid
   x           v_array
   y           
   z           
где v_array - вообще строка, допустим; в такой строке я могу перечислить вершины через пробел (или не важно через что) и в последствии при считывании разбивать на количество вершин, которое там записано. Однако в этом случае я снимаю с БД некоторую часть функционала, а, следовательно, перекладываю на приложение ответственность за целостность и непротиворечивость данных - тоже вроде как не комильфо...

Вопрос : как лучше поступить в такой ситуации? Наверняка задача достаточно тривиальная, чтобы иметь некоторое стандартное решение, которое, в силу моей неопытности, не приходит в голову.
...
Рейтинг: 0 / 0
20.01.2014, 13:45
    #38531770
DarkMaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
letete,

У тебя плоские фигуры => каждая точка имеет 2 координаты (x,y). Откуда ты еще z взял неясно.
Отсюда вывод:
1 таблица FIGURES
id -
Name - наименование фигуры
2 таблица POINTS
id
figure_id - ссылка на фигуру
x
y

Извлекать точки можно по id фигуры. Все равно в какой последовательности. Связь 1 ко многим.
...
Рейтинг: 0 / 0
20.01.2014, 13:47
    #38531773
DarkMaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
letete,

Надеюсь, ты догадался, что точки - это координаты вершин фигуры. ;)
...
Рейтинг: 0 / 0
20.01.2014, 14:11
    #38531804
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
DarkMaster,

т.е. ты предлагаешь наоборот сделать: не в FIGURES ссылаться на POINTS, а в POINTS делать ссылку на FIGURES?

типа так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
POINTS                               FIGURES
uid    fig_id   x     y              uid      name
 1       1      0     0               1         triangle
 2       1      0     2               2         square
 3       1      2     0
 4       2      0     0
 5       2      2     0
 6       2      2     2
 7       2      0     2
я-то почему-то думал, что надо какбе точку (вершину) оставить точкой:
Код: plaintext
1.
2.
3.
4.
5.
POINTS                             FIGURES
uid    x     y                     uid      name         p1   p2   p3   p4
 1     0     0                      1        triangle    1    2    3    NULL
 2     0     2                      2        square      1    2    4    3
 3     2     0
 4     2     2

ну чтобы там данные не повторялись и т.д...

ЗЫ координата z не принципиальна для схемы БД, но необходима, ибо поверхности в 3 измерениях находятся.
...
Рейтинг: 0 / 0
20.01.2014, 14:19
    #38531816
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
сделате связующую таблицу между points и firures, через нее привязывайте к фигуре столько точек, сколько нужно.
...
Рейтинг: 0 / 0
20.01.2014, 14:21
    #38531823
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
господин Матроскин,

поясните как?
...
Рейтинг: 0 / 0
20.01.2014, 14:25
    #38531834
П-Л
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
ТС, вы путаете ссылки в обычных структурах данных процедурных языков и связи реляционных таблиц. В БД детальная таблица Тоски в каждой строке содержит айди мастер-таблицы Фигуры (владелицы деталей).

В обычном языке делается класс Фигура, который содержит массив экземпляров класса Точки.
...
Рейтинг: 0 / 0
20.01.2014, 14:26
    #38531837
П-Л
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
leteteпоясните как?Не менее стандарный кейс в БД - связь М:М делается через промежуточную таблицу, хранящую айди двух объектов.
...
Рейтинг: 0 / 0
20.01.2014, 14:29
    #38531842
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
я правильно понимаю, что должно получиться что-то вроде такого:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
POINTS                     PT_SET                         FIGURES
uid    x     y             uid    fig_id  pt_id           uid      name
 1     0     0              1       1        1             1        triangle
 2     0     2              2       1        2             2        square
 3     2     0              3       1        3 
 4     2     2              4       2        1
                            5       2        2
                            6       2        4
                            7       2        3
...
Рейтинг: 0 / 0
20.01.2014, 14:30
    #38531845
DarkMaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
П-Лleteteпоясните как?Не менее стандарный кейс в БД - связь М:М делается через промежуточную таблицу, хранящую айди двух объектов.

В случае ТС это не нужно - зачем плодить лишние сущности? У него есть фигура, которая описывается набором вершин (точек). Даем каждой точке принадлежность фигуре (figure_id) и все.
...
Рейтинг: 0 / 0
20.01.2014, 14:33
    #38531857
DarkMaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
letete,

Ты же уже написал правильную структуру несколькими постами выше. Задай себе вопрос, что будет делать пользователь (с какими объектами ему нужно манипулировать)? Он будет выбирать фигуру и смотреть/изменять/рисовать ее по координатам вершин или будет вводить координаты точки и смотреть, какая фигура имеет вершину с такими координатами?
...
Рейтинг: 0 / 0
20.01.2014, 14:37
    #38531863
П-Л
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
leteteя правильно понимаю, что должно получиться что-то вроде такого:
Это нужно только если вам заведомо надо хранить "твердый факт" принадлежности точки к несколькм фигурам одновременно.
...
Рейтинг: 0 / 0
20.01.2014, 14:42
    #38531879
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
DarkMaster,

пользователь (программа) будет из точки с некоторыми координатами смотреть на эти поверхности (аналогичным образом объединенные в пространственное тело), что вокруг него и высчитывать до какой короче перпендикуляр (условно). По сути, его интересуют плоскости. (Конечно, можно было бы задавать ее тогда треугольником! Но это приведет с сложному вычислению границ - линий пересечения плоскостей, что утяжелит программу и существенно замедлит ее работу.)
...
Рейтинг: 0 / 0
20.01.2014, 14:45
    #38531885
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
П-ЛЭто нужно только если вам заведомо надо хранить "твердый факт" принадлежности точки к несколькм фигурам одновременно.
а если не нужно?

Вообще говоря, исходя из того, что я написал чуть выше, думаю, да. Этот самый "твердый факт" будет не лишним, ибо в конечном счете пространственное тело не должно иметь разрывов... но на эту тему надо подумать...
...
Рейтинг: 0 / 0
20.01.2014, 14:47
    #38531890
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
leteteDarkMaster,

т.е. ты предлагаешь наоборот сделать: не в FIGURES ссылаться на POINTS, а в POINTS делать ссылку на FIGURES?

типа так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
POINTS                               FIGURES
uid    fig_id   x     y              uid      name
 1       1      0     0               1         triangle
 2       1      0     2               2         square
 3       1      2     0
 4       2      0     0
 5       2      2     0
 6       2      2     2
 7       2      0     2

если вы кодите именно фигуры (порядок обхода важен, заведомая выпуклость не гарантирована) -- т.е. "квадрат" <> "конверт" (два тр-ка по диагоналям и концам |X|), то храните еше и номер вершины (не обязательно сплошной нумератор, но порядок) на обходе. (хотя можете считать что обход задаётся uid-ом poitns-ов.)

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


если точки у вас зачем-то самостийные сущности (не могут быть 2-х одинаковых, а одинаковая точка 2-х поверхностей - одна сущность "точка g") то именно тогда вам в тему предложение матроскина. если вас интересуют только координаты - это лишнее усложнение.
...
Рейтинг: 0 / 0
20.01.2014, 14:50
    #38531896
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
leteteя правильно понимаю, что должно получиться что-то вроде такого:

Да, примерно так.
...
Рейтинг: 0 / 0
20.01.2014, 14:54
    #38531902
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
qwwq,

да, по точке фигуру я не буду искать никогда, однако для обеспечения неразрывности конечного тела, по-видимому, буду проверять пару соседних поверхностей (фигур) на предмет одинаковости двух точек.
...
Рейтинг: 0 / 0
20.01.2014, 15:01
    #38531916
DarkMaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
letete,

Если я правильно понимаю то:
- вытаскиваем все фигуры с их координатами (зачем тут именно фигуры - непонятно, тут проще строить именно плоскости, иначе твои "перпендикуляры из точки" (упрощенно) в большинстве случаев промахнутся мимо фигуры на плоскости, а вот на саму плоскость вполне себе попадут
- строим модель их фигур/плоскостей (для наглядности?)
- выставляем произвольную точку
- пытаемся определить, какая плоскость/фигура ближе

В этом случае (ты будешь смеятся), даже понятие фигуры можно выбросить и заменить ее понятием плоскости, т.к. для построения плоскости нам достаточно 3 точек. А формула определения расстояния от точки до плоскости общеизвестна из курса прикладной геометрии.

Отсюда имеем следующее:
Таблица № раз (пусть будет FIGURES, чтобы не переделывать)
CREATE TABLE FIGURES(ID PRIMARY KEY, NAME VARCHAR(100));
Таблца № два (POINTS)
CREATE TABLE POINTS (ID PRIMARY KEY, FIGURE_ID INTEGER, X INTEGER, Y INTEGER, Z INTEGER);

Заводим 2 плоскости:
ID NAME
1 плоскость 1
2 плоскость 2
Заводим координаты для точек плоскости:
ID FIGURE_ID X Y Z
1 1 1 1 1 -
2 1 2 2 2 координаты для "плоскости 1"
3 1 3 3 3 -
4 2 4 4 4 -
5 2 5 5 5 координаты для "плоскости 2"
6 2 6 6 6 -

Затем:
- выбираем все плоскости
select id from figures
- вібираем все точки для плоскостей
select x,y,z from points where figure_id=:id (id мы получаем на предыдущем шаге).

Примерно так...
...
Рейтинг: 0 / 0
20.01.2014, 16:25
    #38532056
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
leteteqwwq,

да, по точке фигуру я не буду искать никогда, однако для обеспечения неразрывности конечного тела, по-видимому, буду проверять пару соседних поверхностей (фигур) на предмет одинаковости двух точек.

для геометрий в оракел есть ... (запамятовал), что-то, как гугль подсказывает, именуемое "Oracle Spatial", а там -- пакет SDO_GEOM .

в Postgresql есть postgis , а в нём тип geometry (это всё -- и точки, и линии и полилинии и многогранники и мультипойнты -- очень похоже на объекты SDO_GEOM. ф-ии тоже имеют пересечения--аналоги с оракловыми, но аналогия ессно не полная, а логическая).

но если хочется субд-независимости - то наверное мастер(фигура)-слейв(точки) -- оптимальное решение.
...
Рейтинг: 0 / 0
20.01.2014, 17:45
    #38532200
baracs
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
letete,

Может, я не правильно понял с чем вы мучаетесь, но думаю, вам пригодится: Представление поверхности полигональной сеткой .
...
Рейтинг: 0 / 0
21.01.2014, 09:25
    #38532704
mad_nazgul
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
letete Задача : БД поверхностей (плоских), каждая из которых определяется списком вершин (их может быть от, очевидно, 3 до ...)


Берем PostgreSQL и видим, что там уже есть все необходимые типы :-)
...
Рейтинг: 0 / 0
21.01.2014, 12:04
    #38532896
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
mad_nazgul,

я postgresql и буду пользоваться! а что там с типами у нас? есть что почитать может?
...
Рейтинг: 0 / 0
21.01.2014, 12:16
    #38532911
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
mad_nazgulБерем PostgreSQL и видим, что там уже есть все необходимые типы :-)
к сожалению, эти типы предполагают лишь две координаты: аппликата отсутствует :-( это большая печалька...
...
Рейтинг: 0 / 0
21.01.2014, 12:30
    #38532927
letete
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
baracsпригодится: Представление поверхности полигональной сеткой .

Отличная тема! Спасибо! Читаю взахлеб)

но в моей задаче объекты будут простыми: куб, параллелепипед, куб со срезанным углом/ребром, пятиугольная призма, и т.п. - подход на основе полигональной сетки прекрасен, но эту задачу будет усложнять.
...
Рейтинг: 0 / 0
21.01.2014, 12:52
    #38532941
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
БД с заранее не известным числом полей
letetemad_nazgulБерем PostgreSQL и видим, что там уже есть все необходимые типы :-)
к сожалению, эти типы предполагают лишь две координаты: аппликата отсутствует :-( это большая печалька...
чо, в натуре ?

я правда лично пока пользовался только геометрией на геоиде. т.е. двумерной,
но вот выдержка
http://gis-lab.info/docs/postgis/manual/ch06.html ST_X(geometry)

Возвращает координату X точки. Геометрия должна быть точкой.

ST_Y(geometry)

Возвращает координату Y точки. Геометрия должна быть точкой.

ST_Z(geometry)

Возвращает координату Z точки, или NULL, если этой координаты нет. Геометрия должна быть точкой.

2 координаты наверное у стандартного постгрессовского point . он в постгисе не используется.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / БД с заранее не известным числом полей / 25 сообщений из 25, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]