|
|
|
телефонный договор
|
|||
|---|---|---|---|
|
#18+
Всем привет!:) у меня такая проблема. делаю базу данных телефонного оператора (тренировочная база, только учусь). вот есть таблички CUSTOMERS и CONTRACTS. первичный ключ таблицы customers (cust_id) является внешним ключом таблицы contracts. задача такая, нужно создать табличку (additional_contracts). Т.е. дополнительные соглашения. т.е. пользователь может сменить адрес, номер паспорта, тариф и т.д.. вот как сделать так, чтобы если дополнительные солгашения имеются, считывать информацию из таблички additional_contracts, а если их нет, то из обычной таблички contracts. какой вообще должна быть структура таблицы additional_contracts? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2008, 11:19 |
|
||
|
телефонный договор
|
|||
|---|---|---|---|
|
#18+
anastasiaasкакой вообще должна быть структура таблицы additional_contracts? таблицы additinal_contracts вообще не должно быть почитайте хоть книжек по проектированию, чтоль... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2008, 11:49 |
|
||
|
телефонный договор
|
|||
|---|---|---|---|
|
#18+
proposed amendment, была бы благодарна, если бы Вы указали несколько книжек ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2008, 11:58 |
|
||
|
телефонный договор
|
|||
|---|---|---|---|
|
#18+
proposed amendment, и, кстати, почему не должно? ведь нам надо знать не только обновленные данные, но и хранить старые. т.е. просто update не поможет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2008, 12:02 |
|
||
|
телефонный договор
|
|||
|---|---|---|---|
|
#18+
Просто храните все контракты в одной таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2008, 14:19 |
|
||
|
телефонный договор
|
|||
|---|---|---|---|
|
#18+
Чтобы дать и принять совет по делу нужно разобраться в ситуации. Если ваша задача состоит в сборе и хранении первичных документов то в первом приближении для каждой учетной формы нужно завести отдельную таблицу. Но хочу заметить, что для обычного биллинга существенным является движение некой сводной модели абонента, т.е. состояние его услуг, адреса для счетов и т.п. Эта модель не связана непосредственно с первичной документацией (при плохой бюрократической организации такая документация вообще может отсутствовать). В этой модели создавать зависимость от способов создания и изменения контрактных данных нерационально, поэтому имеет смысл сделать одну таблицу "контракт" и отражать в ней все изменения контрактных атрибутов учетной записи абонента независимо от причин и основания их происхождения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2008, 15:16 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35724305&tid=1543516]: |
0ms |
get settings: |
5ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
174ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 196ms |
| total: | 433ms |

| 0 / 0 |
