Eliminate Print Servers: go LANless?
-
@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?
-
@scottalanmiller said:
All ODBC is easy and self describing (Known false.)
First off how is this a known false? Username, password, done. That's easy. If you're referring to the data behind the ODBC, then that's different.
-
@johnhooks said:
@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.
Lots of databases and applications happily do not enforce no-null. So many that it is normally assumed. Nulls are very common. No matter how bad of a form it is, it is the most common way to set up a tuple.
-
@johnhooks said:
@scottalanmiller said:
All ODBC is easy and self describing (Known false.)
First off how is this a known false? Username, password, done. That's easy. If you're referring to the data behind the ODBC, then that's different.
I'm referring to the data behind it.
-
@johnhooks said:
Provide a simple API?
Look at the MangoLassi URL. That's a very common HTTP-based, XML returning, RESTful API.
-
Spiceworks uses a similar API. So easy that you can just look at it.
Have you ever worked with Ruby on Rails? It makes the API for you as you go and drives home how it is used. By default, many modern frameworks create super simple APIs as part of their framework itself.
-
-
@scottalanmiller said:
@johnhooks said:
Provide a simple API?
Look at the MangoLassi URL. That's a very common HTTP-based, XML returning, RESTful API.
an EMR and a forum site are not comparable at all.
-
Second you are assuming that the APIs are going to present the information in a readable way which is a known false.
-
@johnhooks said:
an EMR and a forum site are not comparable at all.
But Spotify is what you are basing things on?
But an API is an API. If you use Ruby on Rails (purely an example) to build an EMR, you'd get, by default, the same API standard.
There is a reason why APIs have standardization, to make them as easy as possible to consume. EMR has no reason not to leverage the same API standard.
-
@johnhooks said:
Second you are assuming that the APIs are going to present the information in a readable way which is a known false.
Not really, the API presents it in the "presented form." Whatever that is. No response is guaranteed to provide a good output, but the API responds with a response that is the vendor's representation of the data. If it is not readable, too bad, you don't have data. But it is what the EMR is giving you. If you use ODBC, you are not using the EMR but bypassing it. Totally different thing.
