Eliminate Print Servers: go LANless?
-
@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
-
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API for this type of system and write the application to use the API securely. With ODBC, all you have to do is figure out the data scheme. With Drupal or Alpha and an ODBC, once I figure out the schema, I can make a whole application to get the info and create a PDF report or similar in about a day to two days.
I do agree with you that the database could be a mess, and then you would be out of luck, but you're also out of luck if there is no way to get the data at all (API or ODBC). The API could also be a mess as well.
In this case, say the API is a mess and you can't get much info from it, but the database is straight forward and they give you read only through ODBC. Would you not use ODBC here?
-
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API ....
why would it need to be a large API? I use APIs all the time that are simple and require no documentation or training. Do we assume that we get that here? No, of course not. But it is certainly an option. but only the API guarantees that we are getting the right data. ODBC means we've bypassed the application.
-
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API for this type of system and write the application to use the API securely. With ODBC, all you have to do is figure out the data scheme. With Drupal or Alpha and an ODBC, once I figure out the schema, I can make a whole application to get the info and create a PDF report or similar in about a day to two days.
My thing is that on one hand you rely on this statement: a single person shop isn't going to have the resources to learn a large API for this type of system and write the application to use the API securely; but then you feel that writing your own application after learning the database schema is likely reasonable and only take a day or two.
On one hand you are dismissing the "correct" way to access the data (and I mean this, through the application is very different than sideband to the application) as too hard but then presenting another option based on the assumption that it will be almost trivially easy.
Could this be the case? Of course. Would I want, under normal circumstances where the vendor hasn't provided everything for the database that I would also need for the API, be willing to do this with medical data? Absolutely not. I'd be taking responsibility for interpreting data that is not mine to interpret. Only if I had full guarantees and documentation would I do this, but that would make an API no more effort (assuming a normal API.)
-
@johnhooks said:
I do agree with you that the database could be a mess, and then you would be out of luck, but you're also out of luck if there is no way to get the data at all (API or ODBC). The API could also be a mess as well.
But it is also important to remember that a single API could be the interface to hundreds of different data sources, which might be old, new, relational, non-relational, etc. and provides a single point of documentation, support, control, etc. for everything.
-
@scottalanmiller said:
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API ....
why would it need to be a large API? I use APIs all the time that are simple and require no documentation or training. Do we assume that we get that here? No, of course not. But it is certainly an option. but only the API guarantees that we are getting the right data. ODBC means we've bypassed the application.
Unless they can tell you what data you need. If you say we need this, that, and the other thing they could tell you what you need. That's still only one part of this though. You have to make the rest of the application.
I mean the whole discussion is moot since he doesn't have API access anyway.
-
A few times you have mentioned needing to secure the use of an API. I feel like you are implying a security concern but I have no idea what it is. What is it that concerns you with an application written to read one data source but not another? In both cases the end user must write a secure application equally, right?
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
My whole reason for this was, a single person shop isn't going to have the resources to learn a large API ....
why would it need to be a large API? I use APIs all the time that are simple and require no documentation or training. Do we assume that we get that here? No, of course not. But it is certainly an option. but only the API guarantees that we are getting the right data. ODBC means we've bypassed the application.
Unless they can tell you what data you need. If you say we need this, that, and the other thing they could tell you what you need. That's still only one part of this though. You have to make the rest of the application.
I mean the whole discussion is moot since he doesn't have API access anyway.
Of either type, no ODBC either, I believe.
