Eliminate Print Servers: go LANless?
-
@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?
-
@scottalanmiller said:
@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.
Spotify's API may not be hard, but that's a ton of info for the small amount of data you're getting. It's going to be a ton of stuff to learn either via API or looking directly at the data. At least the data has to have some kind of structure.
Really the worst it could be in a relational database is one tuple has all of the attributes. I say worst as in worst design. That would be fairly easy to read but horrible design.
-
@johnhooks said:
@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.
But the theory that you need to know nothing and that ODBC will solve the problems is based on this, is it not? If not, then how do you get around the end user needing to know things?
-
@scottalanmiller said:
@johnhooks said:
@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.
But the theory that you need to know nothing and that ODBC will solve the problems is based on this, is it not? If not, then how do you get around the end user needing to know things?
No it's not. You still have to figure things out, but building the application itself is nearly gone (since you're not the only one using it). All you have to figure out is the data, which you would need to do with the API (at least to some extent depending on how it's written).
-
@johnhooks said:
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)
But we've established that you can't just ready through it, right? We are going in circles. Your "it's easy" theory is based on things I'm saying is not necessarily or even likely true. Might be true, sure, but we need it to be "very nearly certainly" true or moreso. This is medical data, it can't be wrong. we are talking about healthcare here. You are willing to put lives on the line based on "well the column names looked like they meant X"?
I'm saying you have to know, not guess. And that your process is based purely on guessing.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@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.
But the theory that you need to know nothing and that ODBC will solve the problems is based on this, is it not? If not, then how do you get around the end user needing to know things?
No it's not. You still have to figure things out, but building the application itself is nearly gone (since you're not the only one using it). All you have to figure out is the data, which you would need to do with the API (at least to some extent depending on how it's written).
But same things again....
- You can't necessarily figure it out.
- You can't necessarily access it.
-
@johnhooks said:
.... which you would need to do with the API (at least to some extent depending on how it's written).
It's not the same. You are talking about replacing an application. I'm talking about using an application. Very different things.
Which is easier to do:
- Look directly at the MangoLassi database?
- Use the website?
or....
- Read a Word document by looking at the ASCII code? or...
- Open it in Word?
-
@johnhooks said:
At least the data has to have some kind of structure.
Here is the rub. This is not only not necessarily true, it's not even likely to be true.
-
@johnhooks said:
Really the worst it could be in a relational database is one tuple has all of the attributes. I say worst as in worst design. That would be fairly easy to read but horrible design.
No, in the best case it would be that, from a "using as a third party" standpoint. That's easier to use than it is even likely to be. You are jumping to a conclusion that isn't even likely. The chances that someone like Spotify uses relational data for their system is actually rather low. Definitely below the 50% mark. It's media, it has no reason for strict relationships and that would introduce a huge cost to them that would make little business sense.
-
@scottalanmiller said:
@johnhooks said:
At least the data has to have some kind of structure.
Here is the rub. This is not only not necessarily true, it's not even likely to be true.
If it's a relational database it has to. Like I said, you can't break the first normal form with a relational database.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
At least the data has to have some kind of structure.
Here is the rub. This is not only not necessarily true, it's not even likely to be true.
If it's a relational database it has to. Like I said, you can't break the first normal form with a relational database.
Sure can, and some relational databases don't even support enforcing it. And there is no reason to even think it is likely to be relational. That's rather unlikely for such a modern app doing what it does. Why is relational even being brought up outside of a "well, I suppose it might be relational."
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
At least the data has to have some kind of structure.
Here is the rub. This is not only not necessarily true, it's not even likely to be true.
If it's a relational database it has to. Like I said, you can't break the first normal form with a relational database.
Sure can, and some relational databases don't even support enforcing it. And there is no reason to even think it is likely to be relational. That's rather unlikely for such a modern app doing what it does. Why is relational even being brought up outside of a "well, I suppose it might be relational."
Explain how it's possible? How can you have a tuple that doesn't have all of the attributes? That's impossible.
-
And again, using Spotify as an anecdote is meaningless. Completely meaningless. You assume everything about their database and then use a complex API to suggest that APIs are difficult. Sure, anyone can make a bad or hard or huge API. But people can also make easy ones. I've used many that are so dead simple that it is just crazy. That doesn't mean that all are.
My point is based on "things come in a wide variety and we can't make assumptions." Your point, I feel, is based on the assumptions that:
- All databases are relational. (Known false.)
- All ODBC is easy and self describing (Known false.)
- All APIs are complex and difficult (Known false.)
- All databases put relationships in the DB not in code (known false.)
Your point depends on all four of those things reliably true, but all are provably unreliable. They might be common (although that too, is questionable) but all are provably not always true. If they are not reliably true, it undermines your point.
My point is simply that we can't know enough to depend on those things.
-
@scottalanmiller said:
And again, using Spotify as an anecdote is meaningless. Completely meaningless. You assume everything about their database and then use a complex API to suggest that APIs are difficult. Sure, anyone can make a bad or hard or huge API. But people can also make easy ones. I've used many that are so dead simple that it is just crazy. That doesn't mean that all are.
My point is based on "things come in a wide variety and we can't make assumptions." Your point, I feel, is based on the assumptions that:
- All databases are relational. (Known false.)
- All ODBC is easy and self describing (Known false.)
- All APIs are complex and difficult (Known false.)
- All databases put relationships in the DB not in code (known false.)
Your point depends on all four of those things reliably true, but all are provably unreliable. They might be common (although that too, is questionable) but all are provably not always true. If they are not reliably true, it undermines your point.
My point is simply that we can't know enough to depend on those things.
Provide a simple API?
