October 6, 2016 at 10:45 am
valeryk2000 (10/6/2016)
drew.allen (10/6/2016)
valeryk2000 (10/5/2016)
CELKO: Do not understand - is it about script from my post of Posted 9/27/2016 10:05:34 PM? This is just a result of query that I originally sent as an Excel file. This is not the way we design tables.Thank you
Joe is what we would call a prescriptivist in linguistics. He has very strong ideas about how SQL should be implemented which are not always practical or even possible within a specific implementation of SQL (e.g. T-SQL). Anything Joe says is about this idealized version of SQL and you need to determine how applicable it is to the real-world situation that you are facing.
Drew
I see ... Well ... I think that it's always good to be reminded of how an ideal SQL should be implemented.
Thank you.
True but a perfect plan never survives its first encounter with the enemy 😎
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 7, 2016 at 11:04 am
Matt Miller (#4) (10/6/2016)
valeryk2000 (10/6/2016)
Sergiy (10/6/2016)
Matt Miller (#4) (10/5/2016)
Sergiy (10/5/2016)
Matt Miller (#4)
Don't forget to incorporate the "sliding window" into your production version of this. In other words - if you're trying to capture all "readmits" in August you'd have to base your selection on July 28th until August 31, 23:59:59.9999; If you're looking for all admissions causing a readmit, you'd need 8/1 through 9/4.
Actually, 7/28 to 9/4.
To register a re-admission on 1 Aug you need to be aware of a corresponding admission in late July.
Right - but you usually are counting either the earlier admit OR the latter, not both at the same time. Same idea though.
May be yrs, may be no.
It depends.
Main thing - OP has the correct understanding and in on the right track.
A caveat: including earlier than '1st of August' admissions would add new ID/ArrivalDateTime that might be taken care of. So to use the 'latter' approach seems to be more appropriate (or not?)
It all depends on the question you're trying to answer. in my previous workplace, we ended up using both options to look at different things: the "earlier was use to profile which cases were likely to readmit, and review if three was something that could have been done differently or were the discharge criteria too aggressive, etc....
The "later" was used to review whether/in what way the condition had changed from the initial readmit. To some degree they ended up using this as well to really validate what was a true readmit (i.e. a continuation of the SAME episode) as opposed to a secondary occurrence which may not be a continuation of the prior one..
If you are still interested (e.g. in health system) - I spoke with our nurses: they are interested in cases when the second admission for the same problem ends in hospital admission.
October 10, 2016 at 11:30 am
CELKO (10/5/2016)
This is the fragment of the table
No, this is not a table at all. A table has to have a key.
From what I've experienced, a table in some sql dialects can lack a key entirely. Are you sure you aren't thinking of a "relation?"
October 10, 2016 at 1:03 pm
From what I've experienced, a table in some sql dialects can lack a key entirely. Are you sure you aren't thinking of a "relation?"
There is actually a good story about this. Back in the 1980's when we were setting the SQL Standards, the relational model was still brand-new. The original SQL products were built on top of existing filesystems. These filesystems. For the most part, depended on indexing for access or on the data being in sorted order (ISAM). The primary key concept was this sorted order in a disguise. This is why Sequel (the original IBM product) had the primary key, and also why Dr. Codd initially put it in the RDBMS model. We literally could not conceive of any other way to do data back then.
Later, Dr. Codd would realize his mistake and corrected his RM to say that a key is a key is a key, and that no keys were more "key-ish" than others. But by then we had already locked SQL into his original model. But it was even worse for us on ANSI X3H2. We debated requiring the primary key on table declarations and decided not to require it. We were worried that we would get to physical in the language description and we had to use existing filesystems, which have no key concept of any kind exclamation. Basically, we chickened out.
Books in Celko Series for Morgan-Kaufmann Publishing
Analytics and OLAP in SQL
Data and Databases: Concepts in Practice
Data, Measurements and Standards in SQL
SQL for Smarties
SQL Programming Style
SQL Puzzles and Answers
Thinking in Sets
Trees and Hierarchies in SQL
October 10, 2016 at 4:25 pm
valeryk2000 (10/7/2016)
If you are still interested (e.g. in health system) - I spoke with our nurses: they are interested in cases when the second admission for the same problem ends in hospital admission.
That must be easy.
Just add another join to HospitalAdmission table on the same PatiaentID and the same ProblemID and within specified time span.
Too trivial. 🙂
_____________
Code for TallyGenerator
October 10, 2016 at 8:07 pm
Sergiy (10/10/2016)
valeryk2000 (10/7/2016)
If you are still interested (e.g. in health system) - I spoke with our nurses: they are interested in cases when the second admission for the same problem ends in hospital admission.That must be easy.
Just add another join to HospitalAdmission table on the same PatiaentID and the same ProblemID and within specified time span.
Too trivial. 🙂
You are right. Actually, admissions are in the same table a fragment of which I presented to your attention. So no additional joins. And thank you for your code.
Val
October 10, 2016 at 8:09 pm
patrickmcginnis59 10839 (10/10/2016)
CELKO (10/5/2016)
This is the fragment of the table
No, this is not a table at all. A table has to have a key.
From what I've experienced, a table in some sql dialects can lack a key entirely. Are you sure you aren't thinking of a "relation?"
I do think of relations. And in the original table ID and ArrivalDateTime comprise a composite primary key
December 18, 2018 at 12:15 pm
CELKO - Monday, October 10, 2016 1:03 PMFrom what I've experienced, a table in some sql dialects can lack a key entirely. Are you sure you aren't thinking of a "relation?"
There is actually a good story about this. Back in the 1980's when we were setting the SQL Standards, the relational model was still brand-new. The original SQL products were built on top of existing filesystems. These filesystems. For the most part, depended on indexing for access or on the data being in sorted order (ISAM). The primary key concept was this sorted order in a disguise. This is why Sequel (the original IBM product) had the primary key, and also why Dr. Codd initially put it in the RDBMS model. We literally could not conceive of any other way to do data back then. Later, Dr. Codd would realize his mistake and corrected his RM to say that a key is a key is a key, and that no keys were more "key-ish" than others. But by then we had already locked SQL into his original model. But it was even worse for us on ANSI X3H2. We debated requiring the primary key on table declarations and decided not to require it. We were worried that we would get to physical in the language description and we had to use existing filesystems, which have no key concept of any kind exclamation. Basically, we chickened out.
That is a good story and a great bit of history, as well, Joe. Thanks for sharing it. Personally, I'm really happy it turned out that way. HEAPs can be incredibly useful especially when it comes to TempDB.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 8 posts - 46 through 52 (of 52 total)
You must be logged in to reply to this topic. Login to reply