This approach is fine as soon as you do not have some 20-30-50 millions of phones in your database with say 3 millions of them has similar hardware upgrade history of 2-3 steps. With the approach described, your model will become overly heavy and overbloated with millions of (rarely used) relationships.
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. 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.
