Which would be the best method to model creadit cards?

[paolodipietro58]

I don't know if this thread would be of interest but let me try:

I have the following concept (maybe nodes?):

1. A Card (million of nodes)
2. A Brand(could be Visa, Mastercard, Amex, JCB, .... not more than 20)
3. A Subbrand (could be standard, platinum, gold, reverse .... hundreds of possibilities)

The same Subbrand (name) could be owned by different brands, and these subbrands are different.
So we have a Classical Visa and a Classical Mastercard as two distinc nodes.

I tried with this model, but I'm unsure: I connected the card to the subbrand, and the relationship has a boolean attribute telling if it is a credit or debit card. All the card info are in the card node: The central unnamed one in the picture.

Do you have other idea on how to model these stuffs? Do you like to to discuss?

[glilienfield]

Maybe a couple comments, nothing critical, but just thoughts:

1. The Error node may have a ton of relationships if you have millions of nodes. This would make it difficult to find cards with a specific error, as you would need to scan each relations for its type. Maybe create an Error node for each type of error and the relationship is 'HAS_ERROR'. This would allow you to find all nodes with an error and all cards with a specific error.
2. I assume a sub brand can have both a credit card and debit card. If so, how about removing the boolean flag in the relationship and use 'Debit' and 'Credit' labels in addition to the "Card" label for cards. This will allow you to search Cards quickly, as well as just "Debit" or "Credit" cards.

Do you have specific querying needs?

[paolodipietro58]

Hi Gary, thank you for your invaluable support!

The error node will have tons of relationships, but we just need it to filter/remove all legacy cards with errors, so we'll never search a card through an error.

About point 2: it looks as a interesting improvement. Just one if was looking for.

In general, our goal is to find a card thru a card hash, which is unique for each card in the world.

We maybe don't need (at the moment) to look for debit or credit cards, but I'll change as you suggested.

Another approach could have been to put brand, subbrand and type into the card as properties and add indexes .... a little bit brutal. What do you think of this latter approach?

[bennu_neo]

Hi!

Just a couple of thoughts.

So a card mush have a hash. This is an indexed property that will allow you to anchor queries on a specific card.

Brand and Credit/Debit conditions can easily be Labels or indexed properties. It depends on the type of queries you are planning to do. If you ever want to traverse based on that property, maybe it's better handled as label. Of course you can do a VISA node but not sure if it brings anything good to your model. e.g. Adding a Visa card, so connecting it to the VISA node, will lock every other creation of a VISA card till this one is not finally commited.

Bennu

[paolodipietro58]

Hi Bennu, thank you for your suggestions.

Yes, you are right: a Brand node doesn't add anything relevant. It can be an indexed property and I should navigate if needed. But this bring us to remove the SubBrand too, for the same reasons.
And, finally, it bring us to my final question: maybe should be better to move brutally everything as a property resulting in a simpler model.

What do you think?

[bennu_neo]

Hi @paolodipietro58

For sure moving everything as property while make your model simpler, but less 'graphy' At that point you may ask yourself if your use case can get any benefit from a graphDB engine. Are you eventually planning to add transactions to this model? Maybe the owners of the cards (so, someone may have different cards)

Bennu

[paolodipietro58]

Hi @bennu.neo

We need a graph engine.
The question is that we have a lot of node types, relationships, transactions, payments, hardware device to control. Maybe an estimate of less than thousand of node types, and tens of millions of nodes and relationships.
Yes, definitely we need a graph DB.

But this doesn't mean that everything must be expressed with relationship, if we don't need to navigate them.

In this particular case, maybe, there could be a low adjunct value to model Brand and SubBrand as separate nodes.

But this doesn't cancel all the other considerations above.

[ameyasoft]

Here is my model:
(Country)->(Bank)->(Brand)->(SubBrand)

[paolodipietro58]

Well, this is true, but where do you attach a CreditCard? (the violet anonymous central node in the graph above)
And the brand/SubBrand are not related to a bank, but to the CreditCard

[ameyasoft]

ameyasoft:

(Country)->(Bank)->(Brand)->(SubBrand)

(Country)->(Bank)->(CreditCard)->(Brand)->(SubBrand)

[paolodipietro58]

No, because I've not a VISA, but a GOLD<-VISA and another one has a GOLD<-MASTERCARD (two different kind of gold)

[ameyasoft]

The Brand and SubBrands depend on the Bank that is issuing the card. 
(Country)->(Bank)->(Brand)->(SubBrand) 
One can search for the Bank that offers the required credit card in a given country. 

Brand indicates VISA/MASTRCARD and SubBrand contains the available options for each brand for a given Bank.

[paolodipietro58]

Well, but for us is true the reverse: we receive a card payment and we know that the payment is done with a Card which has a Brand, a SubBrand and is emitted by a Bank in a Country

And we have to check the card validity AND store the info for future complaints

[glilienfield]

It seems like there is little use for the relationships. It seems storing all these attributes as properties of the card allows you to retrieve this info for audit purposes, resolving disputes, and purging cards with errors. Add indexes on the appropriate properties.