Shiunbird wrote:
spiroyster wrote:
As you say, using a filesystem as a grouping mechanism allows you to structure you data in a tree like hierarchy. However, this means you need to know your data model in advance, and has it's own inherent problems, such as forcing a more relational like tree hierarchy/structure. Fine, until you require another grouping mechanism which does not fit the tree hierarchy representation, this as you say, can be solved with tags (tags on the nodes/data), but the fundamental data is ultimately structured/ordered in tree-like, so is limited with what the tags can do apart from them basically being metadata attached to a bit of data and have no hierarchy themselves (all at root level).
Have you ever worked with a CMDB? I hope you never ever ever have to deal with it.
https://en.wikipedia.org/wiki/Configuration_management_database
At work, we've moved from a custom-made Oracle DB to a proprietary DB by a German company built on top of Oracle (and the most awful front-end), and now we are going to the CLOUD (the miraculous solution to all IT problems). The migration is going to take years, because the vendor won't customize much of it for us so we need to review millions of entries.
You mention in a very theoretical way practical problems we always face:
- you need to enter a set of data that is organised in a way that doesn't fit the initial model. What do you do? Build a custom application that writes and reads in a specific way to the database, and tries to format the data in a way that the other entities accessing the database can utilize and understand.
- you have a mix of automatically-populated data and human-populated data, and then you have applications that rely on both kinds of data as FACTS.
- the odd use case.
For example, we had a colleague in Asia who had NO SURNAME. But the system won't allow blank last names, so:
So we had in different systems:
UserId=1234, FirstName=Name, LastName=.
UserId=1234, FirstName=Name, LastName=[blank]
UserId=1234, FirstName=Name, LastName=[space]
UserId=1234, FirstName=Name, LastName=Name
Most applications would use UserId as unique identifier among different systems (Active Directory, Lotus Notes, SSO, etc..), but some operated on basis of user name.
Her phone would periodically stop working and I've heard once she didn't get paid.
Back to our initial discussion...
We can use the IRIX inventory command, or export lsdev, and write scripts to have the formats matching. But once we have a different use case that reviews a limitation in our way of structuring the data, we have two options:
- review all legacy entries
- watch the beginning of chaos unfold in front of our eyes
The hardest of all is to have the discipline to keep everything updated as we go. I'd love to hear from anyone here who feels being successful with that.
No, will try to avoid, thanks
.
Luckily, I'm a software engineer and we have a dedicated IT dept. to deal with this
. I'm a recent convert, and graph databases have solved design problems for us on at least two occasions. Mainly due to the ability to have multiple data models all represented in a single database (single query interface), and their future proofing. Certainly, you need discipline, and at a higher level, require a vague idea of what you want from the data, but the details can come later
.
They are not the be all end all, and yes, I can approach from a theoretical point of view for fresh data, migrating existing databases would be a right pita (And thank lawd I don't have to do this for a job). We do have lots of third party 'manufacturers' data stored in SQL-esque form which we still need to update, deploy and subsequently query at runtime in the same context as our uber database. However, these can be hidden behind a compatible alternate query language interface rather than migrating it to a single database (although IRL, devs just know which database interface to use...atm... I WILL CHANGE THIS!), but I'm confident a graph database would be able to handle all aspects of this data (and more) should we decide to purify it all.
FWIW, I have implemented a graph-like bespoke database as a PoC for internal representation (which is in fact pretty straight forward, until you want to enforce stuff like ACID transactions o.0), however it looks like we will be using
neo4j
(although I take offence at the jre requirement, but it comes with loads of tools, including nice visual eye-candy tools). Ultimately it doesn't matter as I'm pretty sure most graph-esque query languages can be translated will little effort into other graph-esque queries (explicitly by the user, if not implicitly by the interface). Or at least, I haven't come across any yet o.0 (although I'll be the first to stick my hand up, and admit its a big wide world of databses out there o.0. I'm not hugely experienced with different graph database implementations, more the concepts required for data management).
The cloud is the future imo. I pretty much work via the cloud since I'm part of a distributed development team (we have a dev in NZ! which is literally the opposite side of the planet to me
) and so am I quite happy with its existence as I could not work the way I do without it. I like to think
clouds
mean we have come full circle, we don't have mainframes down the corridors fed by terminals, now we have some grid thingy in (potentially) another country that we interact with via dumb down ARM/Atom clients. In 5 years time, the only requirement for workstations will be for legacy software o.0. I speak from CAD perspective, although it seems like everything is turning into SaaS (even gaming
), which will end up being facilitated puerly by 'the cloud' only. My hypothesis.
<ontopic>
I don't have an inventory of all my kit, but perhaps I should create one, and will post the case study here when I do.
)
. I saw the keywords tips/comments/suggestions in jimmers last post and I went into Code Review mode. Replace the words 'should' and 'NEVER' with 'could' and 'AVOID if possible' respectively in my previous post. Also please note that I didn't compile it, just eyeballed it and noticed that your static wasn't defined.
