-- Thanks and Regards Mahesh Lal
On 18 November 2014 16:28, Andrii Stesin <[email protected]> wrote: > > When modelling, you always need to decide on The Tradeoff: what should be > modelled with relationship, and what with attribute. > > As for me, I developed the following empiric rule for graph data modeling: > if you need more than 10000 relationships to a single node, consider > refactoring it into attribute. > This is really useful. Helps me understand things better. Thanks for sharing this and the detailed solution. > In the case of phones, my solution will follow the following design > pattern. > > First, create and fill (and take care of updating at least monthly!) a > dictionary - set of nodes representing phone hardware models/revisions and > set of nodes for firmwares w/versions, with relationships between them > representing compatibility between hardware and firmware. > > Now let's consider the phone lifecycle in the database, taking care of > firmware versions history and the fact that, quote: "The IMEISV drops the > Luhn check digit in favour of an additional two digits for the Software > Version Number (SVN), making the format > <http://en.wikipedia.org/wiki/International_Mobile_Station_Equipment_Identity#Structure_of_the_IMEI_and_IMEISV_.28IMEI_Software_Version.29>*AA-BBBBBB-CCCCCC-EE" > <http://en.wikipedia.org/wiki/International_Mobile_Station_Equipment_Identity#Structure_of_the_IMEI_and_IMEISV_.28IMEI_Software_Version.29>. > *The > latter adds additional grain of salt to the model: the firmware maker MAY > obey this rule, if he wish, but 1) who may be 100% sure? 2) who knows in > advance, which 2 digits are chosen for what firmware version? So now we > understand, that IMEISV of the phone MAY change in time when the firmware > is updated. Or may not - who knows? The significant consequence is that > *IMEISV > is not a static attribute of the device*, it can be changed (back and > forth) and MAY change in time. > > Now, why on the Earth you consider *technical* phone firmware version to > be an attribute of relationship between phone and the network, which is a > *business* relationship by it's nature? > > So, we start with a phone just unpacked and switched on for the very first > time. Or maybe not the first? We are not sure whether we have anything > already stored in database. The code below is just a sketch, I won't bet it > is executable 'as-is', no warranty: > > MERGE (unit:Device)-[r:HAS_IMEISV]->(i0:IMEISV {IMEISV: > '99-123456-098765-72'}) > ON CREATE SET i0.first_time = TIMESTAMP(), r.first_time = TIMESTAMP(), > unit.first_time = TIMESTAMP() // Ok really we got this phone for the very > first time > WITH unit > MERGE (sim:SIMcard {IMSI: '1234560987654321'}) > ON CREATE SET sim.first_time = TIMESTAMP() > WITH unit, sim > MERGE (unit)-[z:OPERATES_SIM]->(sim) > ON CREATE SET z.first_time = TIMESTAMP() > WITH unit, sim > MERGE (ph:PhoneNo {phone_no: '+380501234567', network: 'MTS'}) > ON CREATE SET ph.first_time = TIMESTAMP() > WITH unit, ph > MERGE (man:Customer {name: 'A'}) > ON CREATE SET man.first_time = TIMESTAMP() > WITH man, unit, ph > MERGE (unit)<-[ud:USES_DEVICE]-(man)-[un:USES_NUMBER]->(ph) > ON CREATE SET ud.first_time = TIMESTAMP(), un.first_time = TIMESTAMP() > RETURN man, unit, ph > > Note that at this step we initially know nothing about firmware/revision > and hardware/revision, and we now have just the following model in the > graph: > > > <https://lh4.googleusercontent.com/-qWe0uw_nVYk/VGsfBVlD_7I/AAAAAAAABaQ/os4s6KN3SXo/s1600/IMEI_1.png> > > But we want to model firmware updates history. Those may or may not affect > the value of IMEISV. Suppose we are not interested in the timescale of > events - when (and through which channel) did customer requested the > firmware update, when it was delivered to him, how much time did pass > between upgrade request and upgrade success or what was the percentage of > unsuccessful upgrade attempts. We just want to reflect the state of the > device with regard to it's firmware. > > Suppose we somehow discovered, that the customer upgraded firmware to a > revision which has firmware_image_id: 'FooSung_GTEX287391UF7C_4.4.2.28732' > and this changed IMEISV to '99-123456-098765-*81*' so now we have: > > > <https://lh3.googleusercontent.com/-FbMkBJCUfnk/VGsmN9d0B7I/AAAAAAAABag/bkg_U1PF7SA/s1600/IMEI_2.png> > > > And note, there isn't a straightforward direct relationship to a node in > the dictionary of firmwares and this is correct - from business point of > view, when 2 devices have equal firmware version, this does not mean any > meaningful connection/relationship between them. And for convenient and > fast search and selection, you just need 2 indices both ON > :IMEISV(firmware_image_id) and ON :FirmwareDictionary(firmware_image_id) > and make sure that values of firmware_image_id are consistent. > > WBR, > Andrii Stesin > > On Sunday, November 16, 2014 11:28:45 AM UTC+2, Michael Hunger wrote: >> >> Mahesh, I like your model, it would be great if the goal for this system >> is to track updates and changes to firmware in a clean way. >> >> But I think if you just need to occasionally check for upgrades per >> customer and see if they skipped something, and if it not the core-use-case >> of the system!! >> >> it might be easiest to just keep the relationship that edo had, update >> its properties and save the previous properties to an new relationship >> called ":PREVIOUS_VERSION" >> >> There might be some benefit to have a dedicated Firmware node per >> firmware version and then have phones relate to each of the firmwares, >> where only one :CURRENT relationship is allowed per phone. But again this >> depends on the model. >> >> -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
