Eliminate Print Servers: go LANless?
-
@johnhooks said:
@scottalanmiller said:
All of this is moot anyway, no EMR vendor is going to consider providing access directly to their raw data. Never going to happen. Ever. So completely out of the question there really isn't a point in discussing it outside of a theoretical "wouldn't it be nice?" Getting API access might be unlikely, but it is a distinct possibility and a feature that better vendors would want to provide as a feature.
http://qrshs.com/paradigm-pm-optional-modules-odbc-connectivity
https://www.henryschein.com/medical-practice-management-software.aspx
There's a few after a quick search.
These provide ODBC access to their hosted database?
-
@scottalanmiller said:
http://qrshs.com/paradigm-pm-optional-modules-odbc-connectivity
This isn't even a business class database. That's Paradigm!
-
@johnhooks said:
@scottalanmiller said:
All of this is moot anyway, no EMR vendor is going to consider providing access directly to their raw data. Never going to happen. Ever. So completely out of the question there really isn't a point in discussing it outside of a theoretical "wouldn't it be nice?" Getting API access might be unlikely, but it is a distinct possibility and a feature that better vendors would want to provide as a feature.
http://qrshs.com/paradigm-pm-optional-modules-odbc-connectivity
https://www.henryschein.com/medical-practice-management-software.aspx
There's a few after a quick search.
I think that you are talking about in house applications used by like three people and I'm talking about hosted systems used by multiple customers. If you cripple your own system with ODBC, no one cares as there is no one to blame and no one hurt but you.
Totally an assumption on my side, but I assumed that when they were getting data from different programs because of different users that these were not systems owned in house. It would be either the hosting provider or the hospital, I would think, that would have to allow ODBC, not your own IT department.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@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.
I don't know what you're saying here. It's either null or it's not. Null has no data, not null is data.
Outside of having a null for id information, if you have a tuple, how do you guarantee that you know its relationship to other tuples? If all you have is a linked list, fine, but that's not a relational database, it's a list. It might be stored in an relational engine and presented via a RDBMS, but it itself isn't relational. You aren't relational until you have more than one table.
Primary and foreign keys.
Not all relational databases even offer these and lots of people don't implement them. You can't assume that they will exist! That's what i've been explaining.
-
@scottalanmiller said:
@johnhooks said:
So in my example, the simplest form would be cust_id, lname, fname, address, city, state, zip, phone, spouse, invoice_number, invoice_date, invoice_amount, etc.
That may be like a giant spreadsheet, but it's still a relational database. If I have a tuple and I don't fill in the spouse attribute, it's null. It's not empty, but null. So that tuple still has an entry for the spouse attribute.
By that logic, all files are relational databases. NoSQL are all relational. A CSV is relational. Just a text file would be.
Null is not valid in traditional relational data. Call it filled or not, it's not considered valid.
Documents aren't because you can literally leave out an attribute in the document. A text file would not be for the same reason.
It's not the best obviously, which is why I said it was a horrible design in the other post and if they have a possibility of being null should be moved to a different table. But that is still considered relational as it fulfills the first normal form.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@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.
I don't know what you're saying here. It's either null or it's not. Null has no data, not null is data.
Outside of having a null for id information, if you have a tuple, how do you guarantee that you know its relationship to other tuples? If all you have is a linked list, fine, but that's not a relational database, it's a list. It might be stored in an relational engine and presented via a RDBMS, but it itself isn't relational. You aren't relational until you have more than one table.
Primary and foreign keys.
Not all relational databases even offer these and lots of people don't implement them. You can't assume that they will exist! That's what i've been explaining.
What relational database doesn't offer pk and fk?
-
@johnhooks said:
Documents aren't because you can literally leave out an attribute in the document. A text file would not be for the same reason.
But I can do that in a tuple, too. That's literally what a NULL is. You can equally record a NULL or use a blank space to represent NULL. Unless you force non-null, you can match it with anything.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@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.
I don't know what you're saying here. It's either null or it's not. Null has no data, not null is data.
Outside of having a null for id information, if you have a tuple, how do you guarantee that you know its relationship to other tuples? If all you have is a linked list, fine, but that's not a relational database, it's a list. It might be stored in an relational engine and presented via a RDBMS, but it itself isn't relational. You aren't relational until you have more than one table.
Primary and foreign keys.
Not all relational databases even offer these and lots of people don't implement them. You can't assume that they will exist! That's what i've been explaining.
What relational database doesn't offer pk and fk?
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@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.
I don't know what you're saying here. It's either null or it's not. Null has no data, not null is data.
Outside of having a null for id information, if you have a tuple, how do you guarantee that you know its relationship to other tuples? If all you have is a linked list, fine, but that's not a relational database, it's a list. It might be stored in an relational engine and presented via a RDBMS, but it itself isn't relational. You aren't relational until you have more than one table.
Primary and foreign keys.
Not all relational databases even offer these and lots of people don't implement them. You can't assume that they will exist! That's what i've been explaining.
What relational database doesn't offer pk and fk?
No enforced FKs in MyISAM, one of the most popular relational engines. At least traditionally it did not. You had to move to InnoDB for that. that's why MyISAM was so fast, it did so much less. And you can always skip it, and tons of people do, even when you use a database engine that supports it.
-
@scottalanmiller said:
@johnhooks said:
Documents aren't because you can literally leave out an attribute in the document. A text file would not be for the same reason.
But I can do that in a tuple, too. That's literally what a NULL is. You can equally record a NULL or use a blank space to represent NULL. Unless you force non-null, you can match it with anything.
That's not the same. It still has the attribute, just null. In a document the attribute may not physically exist at all.
-
@johnhooks said:
It's not the best obviously, which is why I said it was a horrible design in the other post and if they have a possibility of being null should be moved to a different table. But that is still considered relational as it fulfills the first normal form.
Agreed, but it's a pointless definition. If you allow NULL, every text file meets the requirement and the definition is useless.
-
@johnhooks said:
That's not the same. It still has the attribute, just null. In a document the attribute may not physically exist at all.
I don't agree. Once an attribute can be NULL, all possible attributes inherently exist implicitly.
-
If you query a relational database and a non-relational one and ask for an attribute that has not yet been strictly defined, you can still optionally return NULL. Creating the situation where infinite attributes exist and are "defined" by the nature of being queries.
-
Or, as it is often handled by NoSQL systems, the attributes are defined across all documents. So the way that you describe attributes exist equally in, say, MongoDB as in MS SQL Server. They are not handled in the same way, with a central schema, but they exist the same.
-
@scottalanmiller said:
@johnhooks said:
That's not the same. It still has the attribute, just null. In a document the attribute may not physically exist at all.
I don't agree. Once an attribute can be NULL, all possible attributes inherently exist implicitly.
Ok, all possibilities exist, but it's still there.
Here's Codd's definition:
A relation [table] is in first normal form if it has the property that none of its domains [sets of possible values] has elements [values] which are themselves sets.
Having a null value still allows for 1NF.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
That's not the same. It still has the attribute, just null. In a document the attribute may not physically exist at all.
I don't agree. Once an attribute can be NULL, all possible attributes inherently exist implicitly.
Ok, all possibilities exist, but it's still there.
Here's Codd's definition:
A relation [table] is in first normal form if it has the property that none of its domains [sets of possible values] has elements [values] which are themselves sets.
Having a null value still allows for 1NF.
I agreed with you. I only pointed out that it makes all data files relational and becomes a worthless definition without any purpose to use it.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
That's not the same. It still has the attribute, just null. In a document the attribute may not physically exist at all.
I don't agree. Once an attribute can be NULL, all possible attributes inherently exist implicitly.
Ok, all possibilities exist, but it's still there.
Here's Codd's definition:
A relation [table] is in first normal form if it has the property that none of its domains [sets of possible values] has elements [values] which are themselves sets.
Having a null value still allows for 1NF.
I agreed with you. I only pointed out that it makes all data files relational and becomes a worthless definition without any purpose to use it.
Ok. I mean they have to be relational at some level. There has to be some pointer to get the info from.
-
Crap I copied a big thing I typed before and then copied something else ha.
-
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
