Accessing things via ID or name?

Hi,

I've been working for two years now at my current workplace and since the first day we are discussing about our API.

The system saves data in form of two trees: The first tree defines objects like "Customer" and "Name", "Address", "Service Level". The second tree has some kind of folder hierachy and then concrete customers. When there is a customer node, there have to be the predifined child nodes, which then hold a value.

Now the problem: When I am looking for specific customers, I want to send a request to our webservice, which returns a list of customers with a specified service level. Thing is, the service level has to be accessed by its ID in the definition tree. When I have a customer node and want to get the name, I have to ask for the child node with ID of the name node in the definition tree, not by asking for a node called "Name" -> node.getChild(56); [in this case 56 is the ID of the node "Name" under customer in the definition tree]

This is a simplified description of our API. In my opinion, as a user of an API, the API has to hide its inside and just needs to show me how I have to use it. In our case, I have to know precisly what the inside of the two trees look like, in this case what the ID of a node is. For me this is like not asking for files on my disk but like entering the bits and bytes of the position, or like not using URLs but always entering IPs when I want to surf the web.

What is your opinion on our discussion at work?

First off, it sounds like a database might be a better choice than a file system.

But if you're going to stick with the file system, then you definitely should NOT be writing code like node.getChild(56). That's just asking for all kinds of trouble.

Define a layer to translate from meaningful names to those IDs. It might be an enum, so that you can do [/b]node.getChild(NodeId.NAME)[/b] or it might be some kind of mapping of Strings so you can do [/b]node.getChild("name")[/b] (which is more error prone but might also be somewhat more flexible) or just specific methods like node.getNameChild(). You may even implement one of these approaches on top of another.

Which specific approach is right for your situation, I cannot say, but if you're not using consistent, meaningful, centralized names for these things, then you're doing it wrong.

M Bryan wrote: or like not using URLs but always entering IPs when I want to surf the web.

Slight correction: The choice you're talking about here is not between URL and IP address, but between host name and IP address. Your browser requires a URL, but the "host" portion of that URL can be in the form of a name or an IP address.

Jeff Verdegan wrote:First off, it sounds like a database might be a better choice than a file system.

But if you're going to stick with the file system, then you definitely should NOT be writing code like node.getChild(56). That's just asking for all kinds of trouble.

Define a layer to translate from meaningful names to those IDs. It might be an enum, so that you can do [/b]node.getChild(NodeId.NAME)[/b] or it might be some kind of mapping of Strings so you can do [/b]node.getChild("name")[/b] (which is more error prone but might also be somewhat more flexible) or just specific methods like node.getNameChild(). You may even implement one of these approaches on top of another.

Which specific approach is right for your situation, I cannot say, but if you're not using consistent, meaningful, centralized names for these things, then you're doing it wrong.

Even then, the system does not look scalable. If there is no way to get out of it, perhaps you could abstract the "identifying data" to a database and then once you run simple queries on DB(say fetch id by name), you can go to the Tree info.

Jeff Verdegan wrote:First off, it sounds like a database might be a better choice than a file system.

I can see your point. Our use cases are way bigger than just customer and names, everything is much more complex, which legitimates the file system.

But if you're going to stick with the file system, then you definitely should NOT be writing code like node.getChild(56). That's just asking for all kinds of trouble.

Define a layer to translate from meaningful names to those IDs. It might be an enum, so that you can do [/b]node.getChild(NodeId.NAME)[/b] or it might be some kind of mapping of Strings so you can do [/b]node.getChild("name")[/b] (which is more error prone but might also be somewhat more flexible) or just specific methods like node.getNameChild(). You may even implement one of these approaches on top of another.

Which specific approach is right for your situation, I cannot say, but if you're not using consistent, meaningful, centralized names for these things, then you're doing it wrong.

My suggestion was asking for nodes using a scheme like the package system in Java, it could be node.getChild("System.Groups.Customer.Name");.
The thing is: All my coworkers are having an engineering background with chemistry or physics, when they are programming they are happy if everythings works. For other things I tried to convince them I tried to find sources in books that prooved my points. Is there any good source that helps me convincing them not to use IDs as an identifier?

M Bryan wrote:

Jeff Verdegan wrote:First off, it sounds like a database might be a better choice than a file system.

I can see your point. Our use cases are way bigger than just customer and names, everything is much more complex, which legitimates the file system.

If the structure and relationships are complex, that's all the more reason to use a DB. Not that it's likely you'll be able to make that change any time soon.

But if you're going to stick with the file system, then you definitely should NOT be writing code like node.getChild(56). That's just asking for all kinds of trouble.

Define a layer to translate from meaningful names to those IDs. It might be an enum, so that you can do [/b]node.getChild(NodeId.NAME)[/b] or it might be some kind of mapping of Strings so you can do [/b]node.getChild("name")[/b] (which is more error prone but might also be somewhat more flexible) or just specific methods like node.getNameChild(). You may even implement one of these approaches on top of another.

Which specific approach is right for your situation, I cannot say, but if you're not using consistent, meaningful, centralized names for these things, then you're doing it wrong.

My suggestion was asking for nodes using a scheme like the package system in Java, it could be node.getChild("System.Groups.Customer.Name");.

Sure, you can still apply the same suggestions as above, but you just have to add a layer to split the string up appropriately and map each level.

The thing is: All my coworkers are having an engineering background with chemistry or physics, when they are programming they are happy if everythings works. For other things I tried to convince them I tried to find sources in books that prooved my points. Is there any good source that helps me convincing them not to use IDs as an identifier?

Sorry, can't help you there. Maybe the best you can do is to start a grass-roots movement under their feet, changing things as you come across them. When you have to work with something you've already changed, you'll get done quicker and with less fuss, and when they have to do it, it will be easier for them too (though they may not want to admit that at first).

Your point about APIs hiding details is a very good one. Refer to Joel Spolsky's (Joel On Software) articles on Leaky Abstractions for authoritative backing on your point.

M Bryan wrote:I can see your point. Our use cases are way bigger than just customer and names, everything is much more complex, which legitimates the file system.

I'd be interested to see that justification in full, because it'd be the first time I've ever heard a claim that a flat file system is faster than a db substantiated.

Jeff Verdegan wrote:If the structure and relationships are complex, that's all the more reason to use a DB...

Hear, hear. Some databases even allow you to keep references to files, which might make the migration process less painful.

Not that it's likely you'll be able to make that change any time soon.

Perhaps not, but unless M Bryan's company starts planning for it NOW, it'll never happen.

Winston

Winston Gutkowski wrote:

M Bryan wrote:I can see your point. Our use cases are way bigger than just customer and names, everything is much more complex, which legitimates the file system.

I'd be interested to see that justification in full, because it'd be the first time I've ever heard a claim that a flat file system is faster than a db substantiated.

The trees are saved in a database, with ID and parent ID.

M Bryan wrote:The trees are saved in a database, with ID and parent ID.

So you've already got a database then. Even more reason for using it as God (or is that Codd?) intended, I would have thought.

Winston

Winston Gutkowski wrote:

M Bryan wrote:The trees are saved in a database, with ID and parent ID.

So you've already got a database then. Even more reason for using it as God (or is that Codd?) intended, I would have thought.

What do you mean by God and Codd?

M Bryan wrote:What do you mean by God and Codd?

Codd - The Father of relational database theory.
God - The Father of all things (according to many).

Winston

Jokes never work on the net. Least of all religious puns.