Eliminate Print Servers: go LANless?
-
The problem is not that all possibilities exist... it's that it is common for relational database systems to not have purposefully or predictably relational data. You will often get data that cannot be determined from its visible structure or may not be accessible at all. The issues are that it is very common to not do the things that you are relying on for letting end users query other people's systems.
-
@johnhooks said:
Ok. I mean they have to be relational at some level. There has to be some pointer to get the info from.
Equally relational, though. Once you are just down to the single table with NULLS model, pretty much everything is equal.
-
@johnhooks said:
Crap I copied a big thing I typed before and then copied something else ha.
Ha ha
-
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API for this type of system and write the application to use the API securely. With ODBC, all you have to do is figure out the data scheme. With Drupal or Alpha and an ODBC, once I figure out the schema, I can make a whole application to get the info and create a PDF report or similar in about a day to two days.
I do agree with you that the database could be a mess, and then you would be out of luck, but you're also out of luck if there is no way to get the data at all (API or ODBC). The API could also be a mess as well.
In this case, say the API is a mess and you can't get much info from it, but the database is straight forward and they give you read only through ODBC. Would you not use ODBC here?
-
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API ....
why would it need to be a large API? I use APIs all the time that are simple and require no documentation or training. Do we assume that we get that here? No, of course not. But it is certainly an option. but only the API guarantees that we are getting the right data. ODBC means we've bypassed the application.
-
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API for this type of system and write the application to use the API securely. With ODBC, all you have to do is figure out the data scheme. With Drupal or Alpha and an ODBC, once I figure out the schema, I can make a whole application to get the info and create a PDF report or similar in about a day to two days.
My thing is that on one hand you rely on this statement: a single person shop isn't going to have the resources to learn a large API for this type of system and write the application to use the API securely; but then you feel that writing your own application after learning the database schema is likely reasonable and only take a day or two.
On one hand you are dismissing the "correct" way to access the data (and I mean this, through the application is very different than sideband to the application) as too hard but then presenting another option based on the assumption that it will be almost trivially easy.
Could this be the case? Of course. Would I want, under normal circumstances where the vendor hasn't provided everything for the database that I would also need for the API, be willing to do this with medical data? Absolutely not. I'd be taking responsibility for interpreting data that is not mine to interpret. Only if I had full guarantees and documentation would I do this, but that would make an API no more effort (assuming a normal API.)
-
@johnhooks said:
I do agree with you that the database could be a mess, and then you would be out of luck, but you're also out of luck if there is no way to get the data at all (API or ODBC). The API could also be a mess as well.
But it is also important to remember that a single API could be the interface to hundreds of different data sources, which might be old, new, relational, non-relational, etc. and provides a single point of documentation, support, control, etc. for everything.
-
@scottalanmiller said:
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API ....
why would it need to be a large API? I use APIs all the time that are simple and require no documentation or training. Do we assume that we get that here? No, of course not. But it is certainly an option. but only the API guarantees that we are getting the right data. ODBC means we've bypassed the application.
Unless they can tell you what data you need. If you say we need this, that, and the other thing they could tell you what you need. That's still only one part of this though. You have to make the rest of the application.
I mean the whole discussion is moot since he doesn't have API access anyway.
-
A few times you have mentioned needing to secure the use of an API. I feel like you are implying a security concern but I have no idea what it is. What is it that concerns you with an application written to read one data source but not another? In both cases the end user must write a secure application equally, right?
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API ....
why would it need to be a large API? I use APIs all the time that are simple and require no documentation or training. Do we assume that we get that here? No, of course not. But it is certainly an option. but only the API guarantees that we are getting the right data. ODBC means we've bypassed the application.
Unless they can tell you what data you need. If you say we need this, that, and the other thing they could tell you what you need. That's still only one part of this though. You have to make the rest of the application.
I mean the whole discussion is moot since he doesn't have API access anyway.
Of either type, no ODBC either, I believe.
-
@scottalanmiller said:
@johnhooks said:
I do agree with you that the database could be a mess, and then you would be out of luck, but you're also out of luck if there is no way to get the data at all (API or ODBC). The API could also be a mess as well.
But it is also important to remember that a single API could be the interface to hundreds of different data sources, which might be old, new, relational, non-relational, etc. and provides a single point of documentation, support, control, etc. for everything.
True. If it's all relational and the schema is straight forward, ODBC is so much faster. Like I said, without figuring out data schemas I could have the whole thing at least prototyped and running in a day or two. That's with Drupal, so code audited by others for the application itself, and pretty much guaranteed to handle any number of users you want.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API ....
why would it need to be a large API? I use APIs all the time that are simple and require no documentation or training. Do we assume that we get that here? No, of course not. But it is certainly an option. but only the API guarantees that we are getting the right data. ODBC means we've bypassed the application.
Unless they can tell you what data you need. If you say we need this, that, and the other thing they could tell you what you need. That's still only one part of this though. You have to make the rest of the application.
I mean the whole discussion is moot since he doesn't have API access anyway.
Of either type, no ODBC either, I believe.
Yes I submitted that too quickly. I meant to type it but wanted to get something else out ha.
-
Side question, who creates these systems and doesn't use a database per customer? I could see if it's based on Oracle because of the different way they handle schemas and users.
-
@johnhooks said:
Side question, who creates these systems and doesn't use a database per customer? I could see if it's based on Oracle because of the different way they handle schemas and users.
Why make different databases for each customer? That's not how databases are really designed to be used. That would generally be considered bad design. Twenty years ago we used to debate this stuff, but the general consensus was eventually that splitting it up didn't work out well. It hurt performance a lot and was based around a distrust of the database itself.
-
@scottalanmiller said:
@johnhooks said:
Side question, who creates these systems and doesn't use a database per customer? I could see if it's based on Oracle because of the different way they handle schemas and users.
Why make different databases for each customer? That's not how databases are really designed to be used. That would generally be considered bad design. Twenty years ago we used to debate this stuff, but the general consensus was eventually that splitting it up didn't work out well. It hurt performance a lot and was based around a distrust of the database itself.
Fair point about the trust. I never noticed any performance hits, but I haven't managed any that big so that might be why.
-
A database per customer results in weird things too, like having to automate the creation of databases. Which of course you can do, and pretty easily, but it is a step above normal database code and a big weird. If you think about many applications, when they are installed they expect that you are going to have created a database manually for them and set up permissions.
But if you are going to automate database management from the application then the security between databases has to be removed so that the single application can manage them all. Which pretty much defeats the purpose. It's still a single app talking to a single RDBMS, just tons and tons of individual databases to query against.
-
@scottalanmiller said:
A database per customer results in weird things too, like having to automate the creation of databases. Which of course you can do, and pretty easily, but it is a step above normal database code and a big weird. If you think about many applications, when they are installed they expect that you are going to have created a database manually for them and set up permissions.
But if you are going to automate database management from the application then the security between databases has to be removed so that the single application can manage them all. Which pretty much defeats the purpose. It's still a single app talking to a single RDBMS, just tons and tons of individual databases to query against.
Another good point. I was thinking of the recent switch to Epicor that we had. I don't think any of that was automatic. The time it took for them to set everything up and let us know seemed like it was all manual. I guess I was making broad assumptions.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
Side question, who creates these systems and doesn't use a database per customer? I could see if it's based on Oracle because of the different way they handle schemas and users.
Why make different databases for each customer? That's not how databases are really designed to be used. That would generally be considered bad design. Twenty years ago we used to debate this stuff, but the general consensus was eventually that splitting it up didn't work out well. It hurt performance a lot and was based around a distrust of the database itself.
Fair point about the trust. I never noticed any performance hits, but I haven't managed any that big so that might be why.
If you figure you have a hundred databases, might not matter than much. But if you have a thousand, or ten thousand, it can get wonky. You rarely see places with thousands of databases on a single RDBMS.
-
@johnhooks said:
@scottalanmiller said:
A database per customer results in weird things too, like having to automate the creation of databases. Which of course you can do, and pretty easily, but it is a step above normal database code and a big weird. If you think about many applications, when they are installed they expect that you are going to have created a database manually for them and set up permissions.
But if you are going to automate database management from the application then the security between databases has to be removed so that the single application can manage them all. Which pretty much defeats the purpose. It's still a single app talking to a single RDBMS, just tons and tons of individual databases to query against.
Another good point. I was thinking of the recent switch to Epicor that we had. I don't think any of that was automatic. The time it took for them to set everything up and let us know seemed like it was all manual. I guess I was making broad assumptions.
I would assume so, even Wordpress and super simple things don't automate that process at this point.
-
And... you'd need a database to track the databases!
Actually, as I think about it, separating databases really just becomes semantics. As long as it is a single application, separating the databases adds overhead (mostly for the developers) but in reality, it is always still all one datastore. One way or another, the application has to behave essentially the same no matter which way you do it.
The one advantage to having them separate is that you can have different "versions" for different customers. But I'm not sure that that is a good thing.
