|
|
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
Есть таблица transaction_table source_id source_id - источник поступления средств, может быть или наличные (cash) или депозит (deposit) или кредитная карта (credit_card) cash _table deposit _table credit_card_table Как правильно связать transaction_table и таблицы cash _table , deposit _table, credit_card_table ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 18:12 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
srgio cash _table deposit _table credit_card_table 1) надо ли хранить это в 3-х разных таблицах? srgioКак правильно связать transaction_table и таблицы cash _table , deposit _table, credit_card_table ? 2) если да, то XOR ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 18:32 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
1) Не представляю как хранить все в одном- там разные поля. 2) да, в разных. То есть навешивать xor ключ? mysql не поддерживает его. Но это, похоже, вопрос в другой раздел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 19:12 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
srgioТо есть навешивать xor ключ? mysql не поддерживает его. Но это, похоже, вопрос в другой раздел. пример на Оракле Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 20:00 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
Я бы сделал так transaction: account_from account_to .... Account id type name CashAccount id (FK Account) ... ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 20:10 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
belugin Я бы сделал так transaction: account_from account_to .... Account id type name CashAccount id (FK Account) ... ... Так это же тоже самое. Нет? В account id - это и есть source_id. Чтобы обеспечить целостность мы опять упираемся в XOR. Разве нет? Ну или можно поддерживать уникальным id в пределах CashAccount CreditCardAccount, но это не решает проблему как определить в какой таблице что хранться. Проблема не в мапинге, а в поддержании целостности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 21:42 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
s u пример на Оракле Код: plaintext 1. 2. Спасибо. Но увы ограничен postgresql и mysql. Вариант остается только один? Слить все три типа аккаунтов в одну таблицу? :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 21:45 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
s usrgioТо есть навешивать xor ключ? mysql не поддерживает его. Но это, похоже, вопрос в другой раздел. пример на Оракле Код: plaintext 1. 2. Топикстартер просил связь между таблицами, т.е. foreign key. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 22:24 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
miksofts uпропущено... пример на Оракле Код: plaintext 1. 2. Топикстартер просил связь между таблицами, т.е. foreign key. Я так понимаю завести три поля в transaction cash_id credit_card_id и deposit_id. Вешаем ключи на сотвествующие таблицы cash credit_card и deposit. А c помощью constraint добаиваемся чтобы только одно cash_id credit_card_id и deposit_id было установлено. Если я правльно понял s u . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 22:44 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
miksoftПричем тут это вообще? Топикстартер просил связь между таблицами, т.е. foreign key. мне кажется у ТС не составит труда 3 FK создать ( а может и все 6) более интересно как описать что один и только один из этих ФКс может быть источником и только один счетом, куда средства поступили ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2011, 22:48 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
srgioТак это же тоже самое. Нет? В account id - это и есть source_id. Чтобы обеспечить целостность мы опять упираемся в XOR. Разве нет? Насколько я понял по вашему кусочку кода, у вас в табличке Address 3 поля. Что приводит к разреженным записям и трудностям при написании унифицированного кода для работы с табличкой. Да и для расширения типа счета придется проходить по всем таблицам ссылкам и добавлять поле и дописывать constraint. Ну или можно поддерживать уникальным id в пределах CashAccount CreditCardAccount, но это не решает проблему как определить в какой таблице что хранться. Проблема не в мапинге, а в поддержании целостности. Вот что я нашел для SQL server. Может так можно и на оракле? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2011, 15:19 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
belugin4Насколько я понял по вашему кусочку кода, у вас в табличке Address 3 поля. Что приводит к разреженным записям и трудностям Вот сейчас что есть. Но это не правильно. Не смогу я такие fk на account_sources навесить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2011, 16:24 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
srgioВот сейчас что есть. Но это не правильно. 1. date_created и currency_id явно просятся в account_sources 2. зачем object_source_id Не смогу я такие fk на account_sources навесить. 3. Надо наоборот, на стороне cash|credit|deposits сделать по FK на account_sources 4. Вы прочитали материал по ссылке? Поняли? Там еще добавляется в наследники по константному выражению ("тип")и делается FK по паре "тип, ID" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2011, 16:47 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
И связб account_sources <-- account_deposits должна быть не 0..n <- 1 а 1 <- 0..1: для каждого account_deposits должна быть ровно 1 account_sources, но для account_sources может и не быть account_deposits ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2011, 16:52 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
belugin44. Вы прочитали материал по ссылке? Поняли? Там еще добавляется в наследники по константному выражению ("тип")и делается FK по паре "тип, ID" Прочитал. Давайте по порядку. А то или лыжи не еду или не сезон. Там четыре маппинга в классы - Map the entire class hierarchy to a single table - Map each concrete class to its own table - Map each class to its own table - Map the classes into a generic table structure Где во втором и третьем случае type? [img=http://www.agiledata.org/images/mappingClassToTable.gif ] Приведите вашу схему. Я как понял вы за вариант 3 (Map each class to its own table). Так будет проще, там таблицы то четыре всего. А то я вашей идеи не понимаю. Если вы за вариант 3. То получается что вроде этого. Только я не вижу в чем соль? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2011, 14:56 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
Вот, нарисовал в каком-то онлайновом редакторе подобие UML. Множественность тут такая - ---<> 1 : 0..n <|---- 1 : 0..1 Достоинство в том, что - не приходится плодить ссылочные поля по числу видов счетов во всех местах где есть ссылки. - весь код для работы с различным типом счетов унифицируется например, запрос "куда делись деньги со счета X" будет: Код: plaintext 1. 2. 3. 4. Теперь попробуйте переписать его на другой модели. Теперь, допустим, нам надо кешировать хранить остатки на дату в целях быстродействия. Как вы это организуете в своей модели? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2011, 23:32 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
beluginТеперь попробуйте переписать его на другой модели. Теперь, допустим, нам надо кешировать хранить остатки на дату в целях быстродействия. Как вы это организуете в своей модели? Вы лучше скажите как Вы обеспечите чтобы в account были ссылки на существующий тип поступления данных (или кэш или депозит итд ) ? Вот в чем вопрос. s u уже предложил через xor, его решение верное но увы только для oracle. Видимо придется это в коде делать что не есть гуд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2011, 01:10 |
|
||
|
Помогите со структурой
|
|||
|---|---|---|---|
|
#18+
srgioВы лучше скажите как Вы обеспечите чтобы в account были ссылки на существующий тип поступления данных (или кэш или депозит итд ) ? Account сылается на Type. Тут простой FK. Type мы не модифицируем. Соответственно, FK1 таблицы Account проконтролирует существование и единственность ссылки на Type. Это если понимать вашу фразу буквально. Надо еще чтобы для Account существовала ровно 1 запись в BankAccount или CashAccount. Не более чем единственность этой записи контроллируют PK для BankAccount, CashAccount и Account. Соответствие типа и взаимное исключение при существования записей - FK1 для BankAccount, CashAccount и Account. Проблема только в контроле наличия записи - можно вставить запись в Account с Type = 1 и не вставить в запись в BankAccount либо удалить запись из BankAccount. Вот тут я не знаю точно как - за меня это делает appserver ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2011, 02:40 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37381581&tid=1542070]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
400ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 743ms |

| 0 / 0 |
