задачка по базам данных для отцов

voronetskaya

есть две сущности - object и link.
link связывает 2 objectа.
link имеет атрибуты
object имеет скока угодно линков.
то есть типичная связь many-to-many.
надо это на реляционную бд отобразить.
чего хочется. чтобы при выборе всех objectов учавствующих в linkах нужного типа не приходилось делать два селекта - для первого объекта в связи и для второго.
джойнить объекты с линками без мазы, база просто немеряных размеров, это долго.
то же самое для поиска объектов связанных с данными.
в общем хочется полезных советов, как это дело разрулить красиво и правильно.
Ссылки на почитать что-то приветствуются

bonnyboo

select * from link
where link.type == mytype
join object
where object.linkId == link.id
join бысто работает

6yrop

Делаешь, как обычно, нормализованную схему, а потом если надо делаешь material view.
Как делать центральшую таблицу, (лин, объект) или (линк, объект1, объект2 надо смотреть подробнее ситуацию

VitMix

> object.linkId == link.id
Похоже что в этом случае с каждым объектом связано ограниченное число linkов...

2mmail2

Почитать - классика, Коннолли - Берг. Они советуют эту связь просто ещё одной таблицей разруливать.

voronetskaya

если бы джойн работал быстро, вопрос бы не задался.
два селекта из линков(по первой связи и по второй) работают быстрее, чем один селект из объектов с приджойненными линками(ну вот такая немеряная база, объектов там на порядок больше, чем линков)
но делать два почти одинаковых селекта - это как-то некрасиво, хочется все сделать за один запрос и при том быстро...
да,
select obj1, obj2 from link
where link.type == mytype
тоже не покатит, это все делается под хибернейтом , то есть для такого придется еще один класс заводить... в общем, так не катит

bonnyboo

а может ты просто индексы забыл грамотно построить?

sergey_m

Нормальное человеческое решение - это объединение. Если объединение типа table1.integer_type = table2.integer_type работает медленно (не зависимо от размера базы то у вас в консерватории что-то не так. Либо поля по которым делается объединение не integer (тогда вы отморозки либо по этим полям не построены индексы, либо БД по какой-то причине индексы не использует. Какая БД кстати?

voronetskaya

бд оракл, врядли он индексы не использует под виндой все это правда, мож че из-за этого... хз, я ее слава богу не админю
поля ксати не integer а long - по-оракловски number, это плохо? или под "не integer" имелось в виду че-нить типа string?
а вообще, спасибо, я просил именно "нормального человеческого решения", и если оно такое - не буду больше заморачиваться

sergey_m

Сегодня я узнал, что любые числовые данные Oracle хранит в виде строк с десятичными цифрами. Вот так то...

laisan

Видимо, Вас ввели в заблуждение.
SQL> create table test(c_number number)

  2  /

Таблица создана.

SQL> insert into test(c_number)

  2   values(1/10)

  3  /

1 строка создана.

SQL> insert into test(c_number)

  2   values(1)

  3  /

1 строка создана.

SQL> insert into test(c_number)

  2   values(12345678.90)

  3  /

1 строка создана.

SQL> insert into test(c_number)

  2   values(null)

  3  /

1 строка создана.

SQL> insert into test(c_number)

  2   values(0)

  3  /

1 строка создана.

SQL> commit

  2  /

Фиксация обновлений завершена.

SQL> select c_number, dump(c_number, 16)

  2   from test

  3  /

  C_NUMBER           DUMP(C_NUMBER,16)

----------------------------------------------------------

        ,1           Typ=2 Len=2: c0,b                                                               

         1           Typ=2 Len=2: c1,2                                                               

12345678,9           Typ=2 Len=6: c4,d,23,39,4f,5b                                                   

      NULL                                        

         0           Typ=2 Len=1: 80                                                                 

                                                                                

SQL> select chr(80)

  2   from dual

  3  /

C                                                                               

-                                                                               

P

Последний запрос -это чтобы показать, что - это не '0'

sergey_m

Да, мы сегодня поигрались с dump и пришли к выводу, что числовые данные хранятся не в строковом виде конечно же, но в десятичном.
Оставить комментарий
Имя или ник:
Комментарий: