Eliminate Print Servers: go LANless?
-
@scottalanmiller said:
@wirestyle22 said:
No I can't. I don't really do anything with mobile devices so I figured I'd ask questions. Sorry I'm not making a ton of sense
VPN = "Adding them to the LAN when they are far away."
That's it. Nothing more.
Yeah but it should make it visible in a way it wasn't before considering we have no MDM system in place. I was wondering how I might use that to my advantage--if its even possible.
-
My unaddressed concerns with the client/server architecture that we keep going round and round on and I've not seen addressed in any way:
- The complexity of combining many data sources when we have no reason to think we have access to the relational information.
- The fact that systems like this often keep relational data that does exist outside of the database and relationships are created and enforced in software, not the database (I'm working with one of those right now, in fact.)
- The fact that ODBC cannot be automated in big systems like this with simple tools because many datasources have to be combined, not just one.
- That the resulting data cannot be provided by a simple "report" as we need to code something to consume many different data sources into one that we massage ourselves and create our own relationships (maybe some tool does this, I don't know of one.)
- The fact that some data sources cannot use ODBC even if relational, but more likely when they are non-relational.
This leaves us with the basic problems: lack of data integrity, lack of resulting product and inaccessibility of data.
-
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
No I can't. I don't really do anything with mobile devices so I figured I'd ask questions. Sorry I'm not making a ton of sense
VPN = "Adding them to the LAN when they are far away."
That's it. Nothing more.
Yeah but it should make it visible in a way it wasn't before considering we have no MDM system in place. I was wondering how I might use that to my advantage--if its even possible.
VPNs do not make things visible that were not visible before. It just makes them visible when they were not on the local network. If you didn't have the functionality when people were in the office before, adding them to the VPN will not create new functionality.
-
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
-
@scottalanmiller said:
My unaddressed concerns with the client/server architecture that we keep going round and round on and I've not seen addressed in any way:
- The complexity of combining many data sources when we have no reason to think we have access to the relational information.
- The fact that systems like this often keep relational data that does exist outside of the database and relationships are created and enforced in software, not the database (I'm working with one of those right now, in fact.)
- The fact that ODBC cannot be automated in big systems like this with simple tools because many datasources have to be combined, not just one.
- That the resulting data cannot be provided by a simple "report" as we need to code something to consume many different data sources into one that we massage ourselves and create our own relationships (maybe some tool does this, I don't know of one.)
- The fact that some data sources cannot use ODBC even if relational, but more likely when they are non-relational.
This leaves us with the basic problems: lack of data integrity, lack of resulting product and inaccessibility of data.
An API is not some magic thing that suddenly provides all of this. An API has to be written to provide this information. It is the very rare API that provides every thing that a user could want to query.
Even if the API was capable of providing all of this mythical access to information, the user would be in the same spot as the person writing the ODBC query. They would be needing to parse down the API returned information to what they want to see.
Is it less complex than learning SQL? Probably a decent amount, but it is far from simple.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
That in no way disputes what I said.
-
@JaredBusch said:
@scottalanmiller said:
My unaddressed concerns with the client/server architecture that we keep going round and round on and I've not seen addressed in any way:
- The complexity of combining many data sources when we have no reason to think we have access to the relational information.
- The fact that systems like this often keep relational data that does exist outside of the database and relationships are created and enforced in software, not the database (I'm working with one of those right now, in fact.)
- The fact that ODBC cannot be automated in big systems like this with simple tools because many datasources have to be combined, not just one.
- That the resulting data cannot be provided by a simple "report" as we need to code something to consume many different data sources into one that we massage ourselves and create our own relationships (maybe some tool does this, I don't know of one.)
- The fact that some data sources cannot use ODBC even if relational, but more likely when they are non-relational.
This leaves us with the basic problems: lack of data integrity, lack of resulting product and inaccessibility of data.
An API is not some magic thing that suddenly provides all of this. An API has to be written to provide this information. It is the very rare API that provides every thing that a user could want to query.
Even if the API was capable of providing all of this mythical access to information, the user would be in the same spot as the person writing the ODBC query. They would be needing to parse down the API returned information to what they want to see.
Is it less complex than learning SQL? Probably a decent amount, but it is far from simple.
Thank you, you worded this better than I was able to.
Also what software that's used by any number of people at all does the relations in the software vs in the relational database itself. That defeats the whole purpose of the relational database.
So if we are going to assume bad practices here, why not assume bad practices with the API?
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
That in no way disputes what I said.
It does, because I can pull the info out of the relational database and never need to even know NoSQL exists.
-
@JaredBusch said:
@scottalanmiller said:
My unaddressed concerns with the client/server architecture that we keep going round and round on and I've not seen addressed in any way:
- The complexity of combining many data sources when we have no reason to think we have access to the relational information.
- The fact that systems like this often keep relational data that does exist outside of the database and relationships are created and enforced in software, not the database (I'm working with one of those right now, in fact.)
- The fact that ODBC cannot be automated in big systems like this with simple tools because many datasources have to be combined, not just one.
- That the resulting data cannot be provided by a simple "report" as we need to code something to consume many different data sources into one that we massage ourselves and create our own relationships (maybe some tool does this, I don't know of one.)
- The fact that some data sources cannot use ODBC even if relational, but more likely when they are non-relational.
This leaves us with the basic problems: lack of data integrity, lack of resulting product and inaccessibility of data.
An API is not some magic thing that suddenly provides all of this. An API has to be written to provide this information. It is the very rare API that provides every thing that a user could want to query.
Even if the API was capable of providing all of this mythical access to information, the user would be in the same spot as the person writing the ODBC query. They would be needing to parse down the API returned information to what they want to see.
Is it less complex than learning SQL? Probably a decent amount, but it is far from simple.
I'm not saying that it is simple. I'm just saying that a direct client/server connection leaves you without the normally necessary application layer that assembles and protects the data (in terms of integrity.) It's not magic, but neither is ODBC. The idea with a direct ODBC connection is that a computer can look at a bunch of data and just "know" what it represents but it cannot. The problem is that an API is generally needed here, easy or not, because the other option is generally not even reliably possible (or possibly reliable.)
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
That in no way disputes what I said.
It does, because I can pull the info out of the relational database and never need to even know NoSQL exists.
Ah, so if most of the data is relational (and supports ODBC) and some doesn't, you can guarantee that the data not available via ODBC can be just dropped or ignored?
-
@johnhooks said:
Also what software that's used by any number of people at all does the relations in the software vs in the relational database itself. That defeats the whole purpose of the relational database.
Welcome to the real world. Tons and tons of applications do this. It's done so commonly that it is a standard problem to look for when fixing in house code. Is it good? Heck no, but it is sometimes required because of the use of multiple data sources and is becoming increasingly common because of the way that data sources exist today and no matter how bad it is, it is common. I run into it constantly when working with companies that develop their own code.
Does Microsoft do this when writing their own products? of course not. But once you have companies making bad APIs, you have the same pool of developers that aren't making good relationships in their databases.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
That in no way disputes what I said.
It does, because I can pull the info out of the relational database and never need to even know NoSQL exists.
Ah, so if most of the data is relational (and supports ODBC) and some doesn't, you can guarantee that the data not available via ODBC can be just dropped or ignored?
What data are you going to need from a previous doctors visit that isn't permanently stored in the actual storage?
-
@johnhooks said:
So if we are going to assume bad practices here, why not assume bad practices with the API?
I am. And likewise, if we assume good ones, why not assume good ones? I've been pointing out all along that your assumptions were based on a pristine relational database that is fully self describing combined with an API that was hard to use - while possible, it is an unlikely combination and one we would not just assume.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
That in no way disputes what I said.
It does, because I can pull the info out of the relational database and never need to even know NoSQL exists.
Ah, so if most of the data is relational (and supports ODBC) and some doesn't, you can guarantee that the data not available via ODBC can be just dropped or ignored?
What data are you going to need from a previous doctors visit that isn't permanently stored in the actual storage?
I don't understand this question.
-
Because of the way that patient records are often stored and used, as documents, I'd actually be pretty surprised to not find NoSQL in common usage. A quick search on just one popular NoSQL systems turns up that healthcare is specifically a market that they target and there are lots of resources for using it in exactly this kinds of situations.
-
I'm not suggesting that NoSQL or any good programming technique is common in the medical field, I'm just pointing out that relying on an ODBC client server approach creates a requirement that is increasingly impossible to maintain. It doesn't require all or even most data sources using a non-relational system. It requires just one component of any datasource to use something else to keep ODBC from solving the problem.
-
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@Dashrender said:
@Jason said:
@Dashrender said:
I've inquire with the powers that be if they would like a print to mobile device like option.
The thinking is... Instead of paper. The document could just be sent to a phone or ipad/android tablet, etc. 99% of the time the look and throw away... This would avoid the waste.
Anyone see a anything like this?
Unlikely. There's a lot to go on in the backend with something like that.
Sure there could be a lot on the backend... But I would think this would be immensely useful. Though I'm not sure how you'd do it in a LANless setup... I suppose with something like ZT it might be easier.
Does ZT work with mobile devices?
Android today, iOS soon.
That's great. Wow.
And of course any Windows mobile device can use it normally.
Windows phone?
-
@Dashrender said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@Dashrender said:
@Jason said:
@Dashrender said:
I've inquire with the powers that be if they would like a print to mobile device like option.
The thinking is... Instead of paper. The document could just be sent to a phone or ipad/android tablet, etc. 99% of the time the look and throw away... This would avoid the waste.
Anyone see a anything like this?
Unlikely. There's a lot to go on in the backend with something like that.
Sure there could be a lot on the backend... But I would think this would be immensely useful. Though I'm not sure how you'd do it in a LANless setup... I suppose with something like ZT it might be easier.
Does ZT work with mobile devices?
Android today, iOS soon.
That's great. Wow.
And of course any Windows mobile device can use it normally.
Windows phone?
Windows mobile, which is mobile devices running Windows. Not Microsoft's mobile platform which is Windows-ish. I don't believe that the Windows Phone platform is targeted.
-
@scottalanmiller said:
The idea with a direct ODBC connection is that a computer can look at a bunch of data and just "know" what it represents but it cannot.
I have never thought this. I have never connected via ODBC and assumed my computer would just "know" what data I needed and give it to me in a readable format.
What I can say is that it's super easy to use the tools available with ODBC.
For example, I can connect a Drupal or Alpha instance via ODBC and create a form that will read the info from that database in no time. Then I can create a report from this same info by essentially dragging and dropping the attributes I want in the report.
This way I would need to:
A. Figure out the data scheme and choose the attributes(using tools or just reading through it since all attributes have to be the same name, etc)
B. Make a form with your software (Drupal, Alpha, whatever)
C. Build report with the same fieldsWith the API in this instance you would have to
A. Learn the API.
B. Hand write an application to read the info from a user and then get that info from the API.
C. Make sure your code is secure (there is no one else auditing as you write like with Drupal).
D. Use some kind of reporting engine to read the info from the API results. -
A simple architectural example of how this could be used is something like this...
An EHR that tracks patient visit data. It's adhoc info, not highly structured, in documents. So a document database is used to track documents while a relational database is used to track patient financial data and account information. The document database is tied to the account database in the application code.
This is a pretty common design choice today for a lot of reasons and would introduce both relational problems as well as inaccessibility problems to a third party wanting to access databases directly.
Of course, if you are hand coded and willing to be trained by the developers and to take responsibility for any mistakes in the code combining data incorrectly, one could expose one system via ODBC and another via JSON over HTTPS and write a new application to combine them. But wouldn't accessing a single API be potentially much easier? Especially if that API let you specify the needed data in a single query and know that any changes to the underlying system are abstracted away and accuracy is not the end user's responsibility?
