Eliminate Print Servers: go LANless?
-
@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.
-
@Jason 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.
Even on site a lot of programs shouldn't give direct access. Wouldn't that be a violation access controls and audit. We have many programs which install the DB and we never get the encrypted SQL passwords for them.
You could make those things secure from an access perspective, but it would be a pain. It would mean maintaining two sets of access controls and needing to protect the data in ways that may not have been planned for or foreseen or, at least, having to go through extra work to secure them properly and think through more scenarios. It's a large attack surface and more complexity to deal with.
The bigger concerns are typically around performance. Letting people write their own queries means you cannot enforce optimization - the tools that you use to make your main application fast and efficient and the full time database people or ORM tools are not in use and there is a possibility of tons of complex, expensive queries hitting the database. Sure you could limit access times but.. more complexity and people management to deal with.
There are really special cases where things like data analysts have full access and a reason to do things so complex that they need the ability to query directly - but typically they are also given their own databases as well and not part of the normal data pool because of it.
-
@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.
-
@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.
The first normal form doesn't deal with other relations. It only says that tuples in a relation need the same attributes. You can't have a tuple with more or less attributes than other tuples in the same relation.
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.
-
@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.
-
@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.
-
@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.
