Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
Я тут попробую создать в Студии копию учебной БД utlsampl из комплекта Oracle. Вот ddl исходной БД: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Вот что я сделал на 'Студии': Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. Поправьте где сделал не так. Особенно ссылочный ключик deptno. И подскажите где сделать лучше или изящнее. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2010, 19:59 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
mayton, Думаю, примерно так должно было быть: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. В дальнейшем, запросы могут строиться в т.ч. так: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 02:59 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
mayton Поправьте где сделал не так. Думается словесное описание задачи или проблемы более предпочтительно нежели некий код не содержащий ни одного коментария... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 08:41 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
Utlsampl шёл без комментариев. Это учебная базёнка из комплекта дистрибутива Oracle. Есть сотрудники Employees(emp) и подразделения Depts(dept). Каждый сотрудник включается в одно подразделение. Кроме того сотрудники выстроены в иерархию по ссылочному ключу на родителя MGR. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 10:40 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
kolesov, Спасибо. Еще вопрос. Property dept As User.dept Является-ли эта запись по смыслу ссылкой на объект Dept? Не было-ли еще более лучшим вариантом создать агрегацию? Что-то вроде "подразделение содержит внутри себя список сотрудников". dept(1)emp(*) Если можно, то как? Какой из вариантов правильнее идеологически? Какой оптимальнее с точки зрения производительности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 10:43 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
maytonProperty dept As User.dept Является-ли эта запись по смыслу ссылкой на объект Dept? Не совсем так... Восновном такая конструкция применяется при создании "сложных" свойств типа "адрес" или например "документ"... maytonНе было-ли еще более лучшим вариантом создать агрегацию? Что-то вроде "подразделение содержит внутри себя список сотрудников". Для этого применяются связи один ко многим... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 11:09 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
Просто на первых страницах "Кирстена...." я видел картинку вроде UML диаграммы, где видно как один класс содержит в себе другой. Вот и вопрошаю. Это просто связность двух таблиц или действительно контейнерность одного объекта в другом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 11:16 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
mayton, Вы можете использовать отношение (one-many или parent-children), например, так: пример Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. PS: если важно сохранить ограничения для числовых типов, то посмотрите Map SQL datatypes to their Caché equivalents ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 11:18 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
maytonКроме того сотрудники выстроены в иерархию по ссылочному ключу на родителя MGRТогда, наверное, вместо Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 11:57 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
Alexey Maslov Действительно. Я не заметил. Прошу прощения. maytonПросто на первых страницах "Кирстена...." я видел картинку вроде UML диаграммы, где видно как один класс содержит в себе другой. Вот и вопрошаю. Это просто связность двух таблиц или действительно контейнерность одного объекта в другом? Важно учитывать некоторые вещи: 1) как данные в том или ином случае хранятся в БД на уровне глобалов; 2) как будет производиться в дальнейшем работа с этими данными. Объектная Модель Caché Использование Многомерного Хранения SQL и Объектами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 12:28 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
Ну всё. Грузанули меня терминологией. Я как и всякий RDBMS-совец свято верю, что и Cache и любая другая СУБД используют одни и те-же фундаменальные структуры данных типа B+дерева, хеш-таблицы и LRU-списков. Но Cache хвалят за перформанс на некоторых типах задач где есть небольшая денормализация и причём она не нарушает правила проектирования баз Cache а вроде-бы даже органично вписывается. На данном туповатом примере я для себя хотел разобраться в чём-же собака зарыта. И действительно-ли контейнерность связана с денормализацией или это просто синтаксический сахарок. Вы меня толкнули в чтение глобалов. Ну.. если им нет аналога в класических SQL-парадигмах то мне остаётся пойти читать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 12:35 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
Вам скорее всего и не придётся работать с данными напрямую через глобалы. Но знание того, как(где) данные таблиц/объектов хранятся в базе, поможет Вам (точнее администратору СУБД) лучше управлять ими. Например, повысить масштабируемость системы, используя отображение части данных на другие базы. Прикладному разработчику эти знания помогут, например, при доступе через SQL к свойствам из списка встроенных объектов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 13:09 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
servit, Если не сложно, поясните плиз, что в этом случае даст внешний ключ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 14:20 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
krvsamaytonProperty dept As User.dept Является-ли эта запись по смыслу ссылкой на объект Dept? Не совсем так... Нет уж... давайте врать одинаково! ;) По смыслу это означает как раз то, что свойство dept по типу - объект и хранит в себе ссылку на экземпляр оного ;) Агрегацию - можно. Есть тип отношения "родитель-потомок". Использовать его бессмысленно - потомок норовит со временем отделиться от родителя, обрастая новым поведением и свойствами (прямо как в жизни), а ограничения начального выбора типа отношения этого не разрешают. В нашем случае невозможно будет перевести сотрудника из отдела в отдел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 14:34 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
Давайте упростим постановку. Забудем об иерархии сотрудников. Есть просто плоский список emps. Которые входят в depts. Этот листинг будет однозначным? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. Или всё-таки есть варианты объявления контейнерами dept? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 14:42 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
mayton Я подготовил один очень простой, но наглядный пример того, что важно знать/понимать схему хранения данных класса. Итак, дан класс с тремя строковыми свойствами. Задача - создать хотя бы одну запись, с заполненными всеми тремя полями значениями с максимальной длиной. Например, строками, заполненными соответственно символами 'a','b','c'. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Пример заполнения для SQL: Код: plaintext kolesov В данном случае - ничего. Это скорее была демонстрация того, что если отношения не подходят, то можно использовать внешний ключ для SQL (OnDelete/OnUpdate). Конечно, стоило бы взять это в комментарий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 14:47 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
mayton Ещё вариант Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 15:09 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
servit, это вариант. А я сохраню возможность бегать SQL-запросами по связке EMP->DEPT или я лишаюсь этого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 15:12 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
maytonservit, это вариант. А я сохраню возможность бегать SQL-запросами по связке EMP->DEPT или я лишаюсь этого? Лишаетесь, однако это Вам вроде бы и не нужно - сами же хотели спрятать emp`ов за интерфейсом dept`а, или я что-то пропустил? Есть отношение "родитель-потомок" оно прячет сторону "много" более качественно. Черта с два потом концы найдешь ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 15:19 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
maytonНе было-ли еще более лучшим вариантом создать агрегацию? Что-то вроде "подразделение содержит внутри себя список сотрудников". dept(1)emp(*) Если можно, то как? Какой из вариантов правильнее идеологически? Какой оптимальнее с точки зрения производительности? Как-то так: Class User.dept Extends %Persistent { Relationship emps As User.emp [ Cardinality = children, Inverse = dept ]; } Class User.emp Extends %SerialObject { Relationship dept As User.dept [ Cardinality = parent, Inverse = emps ]; } Второй класс в данном случае - встраиваемый, по нему, соответственно, вообще нельзя делать запросов ;) во всяком случае, sql-запросов... Но, в третий раз повторюсь, это будет работать криво. Гораздо "идеологически правильнее", производительнее и надежнее использовать вариант с отношением между хранимыми классами.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 15:32 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
mayton Сразу оговорюсь, что в примере выше предпочтительней использовать массив, а не список объектов. В случае с массивом будет три таблицы: dept , emp и dept_emps . Из таблицы dept_emps Вы можете обращаться к обеим таблицам через "->", например: Код: plaintext Наличие ссылки на самого себя (поле mgr ) в классе User.emp уже не даёт Вам возможности использовать его как встраиваемый класс. Чем для Вас плох вариант с one-to-many? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 15:51 |
|
||
|
Я тут попробую...
|
|||
|---|---|---|---|
|
#18+
kolesovПо смыслу это означает как раз то, что свойство dept по типу - объект и хранит в себе ссылку на экземпляр оного ;) Это только частный случай... Если класс не персистент (ну или не сводится к оному) - никакого экземпляра небудет. И ссылки соответственно тоже. Данные будут храниться прямо в экземпляре "главного" класса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2010, 18:42 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=36892227&tid=1557940]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 251ms |
| total: | 408ms |

| 0 / 0 |
