Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Проектирование простой базы телефонной книги
|
|||
|---|---|---|---|
|
#18+
Реквестирую советы от гуру ER-моделинга. Есть такой скрипт создания БД. В базе таблица subscriber (абонент) связан с таблицей address отношением многие-ко-многим (несколько людей могут жить по одному адресу, один человек в разное время может бить по разным адресам). Первичные ключи в Postgres задаются как SERIAL (автоинкремент). Связь реализована таблицей sub_link. В ней поле sub_id - внешний ключ для sub_id в таблице "абонент". При добавлении записей в каком заполнять таблицы? Сначала создать запись в таблице абонента, потом в таблице адреса, и только затем заполнять таблицу связи? Как устранить проблему с возможностью повторного ввода одного и того же адреса? На клиенте проверять ввод и предлагать связать нового абонента с существующим адресом? При добавлении записей в таблицы subscriber и address надо настроить таблицу связи и создать там запись (ид абонента, ид адреса). Как получить SERIAL ключ только что вставленных записей из первых двух таблиц и не просесть по производительности? Код: plsql 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. 37. 38. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2016, 23:48 |
|
||
|
Проектирование простой базы телефонной книги
|
|||
|---|---|---|---|
|
#18+
memset, 1) контроль по КЛАДР ; 2) не всегда удобно работать с сильно нормализованной базой данных, т.е. в данном случае вместо М-М можно подумать над схемой 1-М или даже 1->1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2016, 06:04 |
|
||
|
Проектирование простой базы телефонной книги
|
|||
|---|---|---|---|
|
#18+
memsetПервичные ключи в Postgres задаются как SERIAL (автоинкремент). Это вы что-то придумали, неверное утверждение. Конструкция (а не тип) `serial` является обёрткой, которая позволяет определить колонку типа `integer` и повесить на неё последовательность с `DEFAULT` выражением. Ключи указываются независимо от `serial`, если не указать, то ключа не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2016, 08:44 |
|
||
|
Проектирование простой базы телефонной книги
|
|||
|---|---|---|---|
|
#18+
memsetКак устранить проблему с возможностью повторного ввода одного и того же адреса? Суррогатные ключи не устраняют дубликатов (к чему вы и пришли). При наличии сурогатного ключа, как правило, добавляется ещё хотя бы один уникальный ключ на бизнес данные. В вашем случае — всё, кроме `addr_id`, из таблицы `address`. memsetКак получить SERIAL ключ только что вставленных записей из первых двух таблиц и не просесть по производительности? Посмотрите на конструкцию `RETURNING` тут и тут . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2016, 09:11 |
|
||
|
Проектирование простой базы телефонной книги
|
|||
|---|---|---|---|
|
#18+
Я запутался с конструкцией WITH. Прежде всего я создал уникальный ключ на таблице адресов: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. При добавлении новой информации нельзя просто добавить запись в таблицу телефонов, потому что из-за высокой нормализации требуется наличие записи об адресе. Но если вставка в таблицу адресов неудачна (адрес уже есть), тогда слишколм прямолинейный подход к вставке телефона приведет к ошибке. Наверно, справиться с этим можно вложенным запросом, который находит id нужного адреса. Пытаюсь сделать как-то так: Код: plsql 1. 2. 3. 4. Но не понимаю, как при помощи WITH сделать последовательную вставку в несколько таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2016, 17:18 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39295260&tid=1997046]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
75ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 271ms |
| total: | 430ms |

| 0 / 0 |
