|
|
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
JohnSparrow, Спасибо за исчерпывающий трактат о древовидных хранилищах. Придраться практически не к чему. И если он пригодится нашей собеседнице, я считаю, что мучил Вас не зря :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2010, 00:01 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
Пожалуйста Как раз вожусь с обсуждавшимися аспектами "иерархической" темы, потому и писал так много. В смысле - рассуждения вслух и т.д., :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2010, 12:27 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, уважаемые программисты! Скажите пожалуйста, как правильно: При записи данных в таблицу adres , передавать в хранимую процедуру все поля адреса(меня смущает что очень много переменных приходиться передовать хранимой процедуре, для каждого адреса 11 полей - и таких адресов 15), или достаточно передать в хранимую процедуру только код кладр, записываемого адреса, и сделать в хранимой процедуре расшифровку всех полей, сделав запрос к справочнику кладр прям из хранимой процедуры и потом только записать все адресные поля в adres ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 09:44 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
zvezda_t, В прошлую пятницу я пропил свой телепатор. Как теперь Вас понять? Какие 11 полей (и зачем столько), какие 15 адресов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 09:58 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
таблица автор adres ------------- [id] [int] IDENTITY(1,1) NOT NULL, [id_doc] [int] NULL, [type_address] [int] NULL, [cod_kladr] [varchar](50) NULL, [mail_index] [int] NULL, [country] [nvarchar](50) NULL, [region_kind] [nvarchar](50) NULL, [region] [nvarchar](50) NULL, [area_kind] [nvarchar](15) NULL, [area] [nvarchar](50) NULL, [city_kind] [nvarchar](15) NULL, [city] [nvarchar](50) NULL, [populated_kind] [nvarchar](15) NULL, [populated] [nvarchar](50) NULL, [street_kind] [nvarchar](15) NULL, [street] [nvarchar](50) NULL, [house_kind] [nchar](10) NULL, [house] [nchar](15) NULL, [corps] [nchar](15) NULL, [quarter] [nchar](15) NULL Виды адресов: рабочий, домашний, собственности, адрес родителей, и тд (всего их около 15) Хранимая процедура вариант 1) Код: 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. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. вариант 2) Код: 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. Мне кажется первый вариант лучше))). Или я вообще не правильно делаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 10:22 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
zvezda_tМне кажется первый вариант лучше))). Барышня, Вы что-нибудь о нормализации слышали? Вариант 2, кстати, ничем не лучше. В таблице [adres] надо хранить: ID записи, KladrID, номера дома, корпуса, строения, помещения. Опционально можно в порядке денормализации хранить строку адреса, чтобы можно было быстро получить, а не делать CTE-запрос к таблице КЛАДРа. Можно еще почтовый индекс хранить. Еще флажок, что адрес введен от руки можно предусмотреть. И усе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 12:30 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
Senya_Lzvezda_tМне кажется первый вариант лучше))). Барышня, Вы что-нибудь о нормализации слышали? Вариант 2, кстати, ничем не лучше. В таблице [adres] надо хранить: ID записи, KladrID, номера дома, корпуса, строения, помещения. Опционально можно в порядке денормализации хранить строку адреса, чтобы можно было быстро получить, а не делать CTE-запрос к таблице КЛАДРа. Можно еще почтовый индекс хранить. Еще флажок, что адрес введен от руки можно предусмотреть. И усе. То есть моя таблица должна выглядеть так: автор adres ---------------------------------- [id] [int] IDENTITY(1,1) NOT NULL, [id_doc] [int] NULL, [type_address] [int] NULL, [cod_kladr] [varchar](50) NULL, [mail_index] [int] NULL, [house] [nchar](15) NULL, [corps] [nchar](15) NULL, [quarter] [nchar](15) NULL [address] [varchar](255) NULL и в поле address - нужно записывать все поля country,region_kind, region, area_kind,area,city_kind, city,populated_kind,populated,street_kind,street, а если адрес в веден в ручную, то в поле address записывать весь адрес введенный от руки - правильно? Скажите пожалуйста, а если кладр обновить, прежний код кладр будет правильно расшифровываться (я хотела так подробно хранить данные, на случай если код в обновлённом кладере будет отличаться от кода прежнего кладра)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 13:06 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
zvezda_tи в поле address - нужно записывать все поля country,region_kind, region, area_kind,area,city_kind, city,populated_kind,populated,street_kind,streetНе просто "записывать все поля", а хранить строку адреса в соответствии с установленными правилами форматирования. Если от руки введен, то тут уж ничего поделать не можем и формирование строки отдаем на откуп юзеру. У меня поле IsManual так до сих пор не используется, что уберегло от множества ошибок. Зачастую операторы просто не указывают район, а потом голосят, что с. Мусохранска нет почему-то. ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 14:05 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
Senya_LНе просто "записывать все поля", а хранить строку адреса в соответствии с установленными правилами форматирования. Дело в том, что с моей базой работают несколько приложений, и в одном из них адресная строка формируется в виде: автор1) АДРЕС1:РОССИЯ, 105173, Москва г, , , , 9 Мая ул, 28, 3, 3 а в другом: автор2)АДРЕС1:РОССИЯ, 105173, г Москва, , , , ул 9 Мая, д. 28, корпус. 3, кв. 3 и как мне быть? Senya_LНе просто "записывать все поля", а хранить строку адреса в соответствии с установленными правилами форматирования. У меня поле IsManual так до сих пор не используется, что уберегло от множества ошибок. что это за поле -IsManual?? и еще скажите пожалуйста, а если кладр обновить, прежний код кладр будет правильно расшифровываться (я хотела так подробно хранить данные, на случай если код в обновлённом кладере будет отличаться от кода прежнего кладра)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 14:16 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
zvezda_tSenya_LНе просто "записывать все поля", а хранить строку адреса в соответствии с установленными правилами форматирования. Дело в том, что с моей базой работают несколько приложений, и в одном из них адресная строка формируется в виде: автор1) АДРЕС1 :РОССИЯ, 105173, Москва г, , , , 9 Мая ул, 28, 3, 3 а в другом: автор2) АДРЕС1 :РОССИЯ, 105173, г Москва, , , , ул 9 Мая, д. 28, корпус. 3, кв. 3 и как мне быть?А вот это уже интересно. А что, может быть АДРЕС2 в той же строке? Судя по количеству запятых и парсите еще на клиенте. А по поводу нескольких приложений. Если они между собой никак не связаны, то формируйте адресную строку на сервере. авторчто это за поле -IsManual??Признак, что адресная строка сформирована от руки. В этом случае поля KladrID и номера дома, корпуса, помещения должны быть IS NULL. Соответствующий CHECK-ограничение легко составить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 14:50 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
скажите пожалуйста, а если кладр обновить, прежний код кладр будет правильно расшифровываться (я хотела так подробно хранить данные, на случай если код в обновлённом кладере будет отличаться от кода прежнего кладра)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 14:59 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
zvezda_tскажите пожалуйста, а если кладр обновить, прежний код кладр будет правильно расшифровываться (я хотела так подробно хранить данные, на случай если код в обновлённом кладере будет отличаться от кода прежнего кладра)?До кто ж его знает, как вы обновление реализуете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 15:04 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
Senya_LДо кто ж его знает, как вы обновление реализуете. хотела прежний кладр заменить новым и всё. а как правильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 15:11 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
zvezda_tSenya_LДо кто ж его знает, как вы обновление реализуете. хотела прежний кладр заменить новым и всё. а как правильно?Просто "взять и поменять" не получится. Как минимум слетят первичные ключи КЛАДРа. Также придется перенастраивать адресные ссылки (adres.KladrID или как вы его там называете) на новые актуальные элементы. Сверять с ALTNAMES.DBF слияния и прочие сложные преобразования. В двух словах этого не объяснишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 15:57 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
Senya_LПросто "взять и поменять" не получится. Как минимум слетят первичные ключи КЛАДРа. Также придется перенастраивать адресные ссылки (adres.KladrID или как вы его там называете) на новые актуальные элементы. Сверять с ALTNAMES.DBF слияния и прочие сложные преобразования. В двух словах этого не объяснишь. adres.KladrID - это код кладр? ужас... как сложно( где про это можно почитать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 16:05 |
|
||
|
Правильная Организация таблиц в БД
|
|||
|---|---|---|---|
|
#18+
zvezda_tужас... как сложно( где про это можно почитать?А вы думали что вот так вот запросто все сделаете? А читать нужно документацию здесь . Причем непросто читать, а творчески переосмыслить - готовых рецептов там нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 20:30 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1542389]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
436ms |
get topic data: |
8ms |
get first new msg: |
6ms |
get forum data: |
3ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 747ms |

| 0 / 0 |
