|
|
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
Код: 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. Получаю две одинаковые записи Я правильно понимаю, что CONSTRAINT pk_parent_recordid будет проверять только для строк ЯВНО вставленных в parent? И все проверки для child таблиц будут проигнорированы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2013, 23:47:40 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
DmGr Код: 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. Получаю две одинаковые записи Я правильно понимаю, что CONSTRAINT pk_parent_recordid будет проверять только для строк ЯВНО вставленных в parent? И все проверки для child таблиц будут проигнорированы? да правильно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 02:14:15 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
Maxim BogukDmGr[src PLSQL] <> Я правильно понимаю, что CONSTRAINT pk_parent_recordid будет проверять только для строк ЯВНО вставленных в parent? И все проверки для child таблиц будут проигнорированы? да правильно нет неправильно "все проверки" не будут проигнорированы, просто в чайлд 1 своя свадьба (читай - "унаследованный" ПК), в чайлд2 - своя, а в парент - наоборот третья (сс). т.е. никаких кросс-проверок нет, и пока кросс-таблицу не создать ручками, обвязав ФК(что чревато) (или пока разрабы ПЖ это не изменят, а они не собираются) - это так и будет. кактотаг ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 08:33:59 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
Подскажите тогда, как грамотно сделать ограничение уникальности для parent, с учетом, что все записи вставляются в child? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 09:34:34 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
DmGrПодскажите тогда, как грамотно сделать ограничение уникальности для parent, с учетом, что все записи вставляются в child? эффективно надежно и быстро - никак... PS: кстати " пока кросс-таблицу не создать ручками, обвязав ФК(что чревато) " - совершенно не защищает от того что между партициями будут дубликаты (т.е. максимум некоторая защита если триггера не сломаны)... но это хоть какое то решение да... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 10:03:03 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
А можно поподробнее... И почему разработчики не собираются кросс-проверки в PG делать? Ткните ссылкой - почитать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 11:22:33 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
Сейчас посмотрел в доках, долистал до 7.4... inherit This deficiency will probably be fixed in some future release. Неужели это вообще никому не нужно? Как же люди изворачиваются то? Или наследование - это костыль, которым лучше вообще не пользоваться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 12:14:40 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
DmGr, это иногда удобный костыль НЕ для случаев, когда нужен форейн кей. никто не пользуется похоже, да ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 12:35:17 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin Да фиг с ним с FK, хотя бы primary key работал :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 12:39:16 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
DmGr, ну и пк туда же ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 12:44:02 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
DmGrСейчас посмотрел в доках, долистал до 7.4... inherit This deficiency will probably be fixed in some future release. Неужели это вообще никому не нужно? Как же люди изворачиваются то? Или наследование - это костыль, которым лучше вообще не пользоваться? костыль... в основном для 1)архива отчетов/операций... 2)или там где уникальность по PK идет а он из sequence генерируется... 3)или там где таблица уже под сотню гигов и ее надо резать на куски любой ценой ради какой то управляемости хотя бы... а зачем вам вообще партиционирование то в вашей задаче? если вариант 1 - то зачем там вам где то уникальность не понятно... если вариант 2 - то там и проблемы то нет на самом деле если вариант 3 - то а)у вас вариантов особо нет б)вы и сами достаточно грамотный чтобы придумать что сделать если что то 4тое - вероятнее всего оно вам не надо... но можете попробовать изложить задачу и обьяснить зачем вам это надо. PS: cross-table unique check крайне нетривиально реализовать так чтобы это не тормозило. -- Maxim Boguk Senior Postgresql DBA http://www.postgresql-consulting.ru/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 13:38:42 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Я хотел все таки не партиционирование, а именно наследование применить. Я конечно выкручусь и с наследованием, просто хотел у более знающих людей спросить. Ну нет, так нет. Примерный смысл такой Parent - таблица документов (общий журнал всех документов) номер дата тип документа и т.д. Child1 таблица тип документа 1 и его спец часть Child2 таблица тип документа 2 и его спец часть и т.д. Получилось красиво, но вот нарвался... Я прекрасно понимаю, что без наследования прекрасно можно обойтись. Будем считать, что это был мой не совсем удачный опыт. Хотя мне сначала это показалось очень удобным вариантом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2013, 13:58:50 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
Вот такое решение: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. При вставке в наследника триггером добавляется id в doc_id, чем проверяется уникальность. При удалении из наследника триггером удаляется id из doc_id. Следующим уровнем наследования идут партиции по месяцам (doc_specific1_p201401,...). Есть возможность делать внешние ключи "на doc" (фактически на doc_id.id). Кто так делал, в чём грабли? :) Покритикуйте, пожалуйста... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 10:55:31 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
kengooВот такое решение: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. При вставке в наследника триггером добавляется id в doc_id, чем проверяется уникальность. При удалении из наследника триггером удаляется id из doc_id. Следующим уровнем наследования идут партиции по месяцам (doc_specific1_p201401,...). Есть возможность делать внешние ключи "на doc" (фактически на doc_id.id). Кто так делал, в чём грабли? :) Покритикуйте, пожалуйста... само по себе решение как абстрактная штука - рабочее... но как я уже писал партиционирование надо в 3х случаях 1)архива отчетов/операций... 2)или там где уникальность по PK идет а он из sequence генерируется... 3)или там где таблица уже под сотню гигов и ее надо резать на куски любой ценой ради какой то управляемости хотя бы... в варианте 1 и 2 ваше решение просто не надо )... в варианте 3 не будет работать так как задача то не создавать таблицу на несколько миллиардов записей... а у вас в doc_id именно это и будет... (со всеми связанными проблемами). Т.е. да решение... но для несуществующей задачи... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 11:54:56 |
|
||
|
Дубликаты в primary key parent-таблицы
|
|||
|---|---|---|---|
|
#18+
Партиции несомненно нужны, но когда партиции в стиле Оракла будут реализованы - бог весть. А вот для наследования я не нашел достойного применения, кроме как костыли для партиций в Постгресе здесь и сейчас. Все можно сделать через вью ничем не хуже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 22:06:06 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38162008&tid=1998826]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
210ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
75ms |
get tp. blocked users: |
1ms |
| others: | 231ms |
| total: | 569ms |

| 0 / 0 |
