|
Here in Colorado, we had the usual fear monger in the Governor's office screaming about a new, more dangerous variant of COVID yesterday. Right after that clip on the news the station went to a clip at the State Health Department labs where they said they test 7% of the positive cases to determine which variant it is and they haven't seen this new variant yet.
|
|
|
|
|
Or, in this case, the US healthcare industry and the COVID-19 disease.
My health took a turn for the worse about 3 months ago. All of a sudden, I was seriously short of breath when I was out walking. Nah, shuffling my feet rather than walking.
I had been previously diagnosed with myocardial bridge for which the remedy is cardiac bypass surgery.
I decided that I was not going to subject myself to the ministrations of the US healthcare industry or the financial stipulations that would be laid down by the insurance companies.
So, after getting two shots of the Pfizer vaccine in March, I looked for the first available opportunity to leave the US for India.
Reached Calcutta by April 1, where my nephew is a top-ranking physician, who had undergone training in the US. Got admitted to the hospital where medical tests revealed that I have adult onset asthma which would have caused the shortness of breath. In addition, my hemoglobin was 9 as opposed to 13.5 for a healthy male, but for the last 30 years it has been at 10.5 only without causing me too many problems. An angiogram revealed three blocked arteries. Medical protocol requires angioplasty or bypass surgery under those conditions.
A couple of days later, after a blood transfusion and infusion of some iron compound into my body, I was wheeled into the cath lab where the cardiologist put in stents in two blood vessels, deeming that the third could be managed with medication. Stayed in the hospital for two more days and got discharged before the sudden and alarming and deadly rise of COVID cases in India.
Was taken care of by young (and pretty) nurses not yet jaded by seeing too many patients and deciding that fate has more to do with patient’s conditions than nursing care. The hospital administration was employing full-time staff as opposed to deciding staffing levels based on case load. It was wonderful to be in a private suite with 5-star service.
The hospital is a US JCAH-accredited hospital so I don’t think I would have gotten better care in the US.
The bill was less than $9,000 which I gladly paid out of my pocket. It probably was less than the co-pay in the US.
I scanned the detailed bill. I was billed 0.005 US cents for an aspirin. Yes, half a cent. I remember 20 years ago reading reports that in US hospitals, aspirin was being billed at $12 a dose. Who knows how much it costs now!
So I escaped the clutches of the US healthcare industry and COVID just by fortuitous timing.
I am now going on regular walks so that the old ticker gets back into shape.
|
|
|
|
|
But that's... socialism! Tadadada!  
Other than that well done! Lucky to NOT be a US citizen! 
As a side note, now that you mention the pretty nurses, I think I feel unwell as well....
|
|
|
|
|
Super Lloyd wrote: As a side note, now that you mention the pretty nurses, I think I feel unwell as well....
So come to Israel (if you can, at the moment). The care is just as good, and the nurses are just as pretty. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Israeli women are definitely very pretty, in general.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
In the private rooms, the nursing staff were primarily from India’s northeastern states, with a very strong Southeast Asian look. Very petite, very pretty.
In the Cardiac Care Unit, the nursing staff were from Kerala, the state in the southwest of India. Tall, willowy. Many came around just to see me since I could speak Malayalam, their language.
PS. Kerala happens to be the location of the first Jewish settlement in India, dating back to 279 AD, when they landed on the coast and sought protection from the local king. Almost all of their descendants left for Israel after 1948, leaving behind their names inscribed on their houses and a synagogue in the area called Jewtown in Cochin.
|
|
|
|
|
Not socialism but capitalism at its finest.
The hospital is a private for-profit enterprise. They have to compete with other private hospitals in the area. The government of the state of West Bengal does regulate costs to patients of major procedures so the hospital has to stay under that and make a profit. They don’t attempt to do that by skimping on nursing care.
All supplies such as medicines, infusion sets, etc., have to billed at retail list price. The hospital makes a bit of money on those by getting discounts since they buy them in bulk.
I am a naturalized US citizen from India with families in both countries so I was able to return to India for the medical care I needed. But enough persons from the UK and Canada come to India for medical treatment since the elderly are denied “elective” surgery such as cardiac bypass or hip replacement in those countries under NHS rules, which decide that there is no benefit to society by treating the elderly.
|
|
|
|
|
Vivi Chellappa wrote: Not socialism but capitalism at its finest.
and thenVivi Chellappa wrote: The government of the state of West Bengal does regulate costs
And that you call capitalism at its finest? I presume you are being cynical as the government regulation of the price is nothing at all like capitalism.
And just as an aside - between medicare and my private insurance (from previous employment) I would pay, in a US Hospital $0. That is the bill I got from two surgical procedures in 2019 and it's the bill I'd get today.
In actuality, the problem with the US system is it's too damn capitalistic. The MD's organizations both implicitly and explicitly regulate the number who can enter their profession (priesthood) in order to keep it lucrative. The only regulation on hospital pricing is via one's insurance (or medicare) - otherwise, capitalism reins and the prices literally can go up an order-of-magnitude. I've seen bill before they're replace for insurance billing (e.g., blood work) and saw $850+ drop down to about $90. It's legal crime - a part of capitalism that's often ignored by it's knee-jerk level advocates.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It sounds as if you dodged a bullet. Twice.
Stay well.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Well done and glad you're improving.
|
|
|
|
|
The Indian Health Care system did not do a good job protecting the population from Covid, did it? 
Get me coffee and no one gets hurt!
|
|
|
|
|
Vivi Chellappa wrote: I scanned the detailed bill. I was billed 0.005 US cents for an aspirin. Yes, half a cent. I remember 20 years ago reading reports that in US hospitals, aspirin was being billed at $12 a dose. Who knows how much it costs now!
I've heard (on more than one occasion) that the patent on Aspirin expired, and as a result doctors/pharmacists/those who have a dog in that race have since pretty much been trying to sway patients away from it and onto..."alternatives".
Seriously, google "aspirin is no longer recommended" and see what comes up. You'd think it has been killing people all along...
|
|
|
|
|
I know what opinions exist about Entity Framework from the C# developer view.
What do those of you who have to maintain production databases think about developers using Entity Framework?
Does it matter in your job?
Does it positively or negatively affect database design or performance?
Does its use ever cause you any headaches or make your job any easier?
Thanks in advance.
|
|
|
|
|
MSBassSinger wrote: What do those of you who have to maintain production databases think about developers using Entity Framework?
It doesn't matter, it behind a tier.
MSBassSinger wrote: Does it matter in your job?
Np, I have none and for hire.
MSBassSinger wrote: Does it positively or negatively affect database design or performance?
Compared to what, Dapper?
MSBassSinger wrote: Does its use ever cause you any headaches or make your job any easier?
I prefer SQL.
No, we don't prefer it; it had not enough advantages over the proven path. Given it is the third layer, we prefer something proven.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
using EF in my projects ? Are you crazy ?
Have you seen what complicated queries it produces for just one simple table ?
Never in my lifetime...
|
|
|
|
|
Quote: Have you seen what complicated queries it produces for just one simple table ?
Amen to that. And if you are not careful, it will also open multiple connections to the poor database server.
And if you have had the audacity to use views and stored procedures to do a clean database design - oopsie, EF doesn't like that.
I implement the business logic in the database and surface client-ready interfaces via views and stored procedures. That way, something like EF is not needed.
But if you don't have a DBA around, and you are OK with using the database as dumb storage - then EF looks like a good fit.
|
|
|
|
|
There's absolutely nothing in EF that says you have to use the queries it generates. If you see a non-performant query - write the one you want EF to use instead.
And EF handles sprocs perfectly well. It has a slight issue with views that EF requires a PK (unique Entity ID) of some kind - but that can be generated as part of the view.
If you're going to bash EF - make sure you're aware of the current capabilities - not what is was 6-7 years ago.
Phil
|
|
|
|
|
Quote: And EF handles sprocs perfectly well.
Ah, maybe I should have mentioned that we were using it against an Oracle database. It is true that it talked well with SQL Server, but it wasn't at all happy understanding Oracle packages and views.
Quote: make sure you're aware of the current capabilities - not what is was 6-7 years ago.
This was indeed 5-6 years ago, so newcomers will hopefully have a better experience with EF than we had  .
|
|
|
|
|
I think you guys used very old versions of EF, because I'm using EF for almost every project that I start and the queries are actually very clear and concise. In the end you can even execute your own queries with EF, the same way as you do with Dapper, I'm very satisfied with how EF actually works
|
|
|
|
|
Same thoughts exactly.
A lot of DBA's dismiss the earlier versions and never re-evaluate it again, which is a professional mistake in my opinion. It has improved tremendously in the past decade or so, so much so that I would not start a new project/company without it again.
The main reason for it's success, is that it successfully avoids the constant maintenance and performance issues you hit after 5 years or so doing the typical SQL designs. EF is more complex to maintain initially, but it scales up all the way to enterprise, for a fraction of the cost and with a lot less headaches along the way.
Also, the typical "the queries are bad" response I get is disingenuous. All DB designs allow for bad queries, but with EF you get a sustainable way of solving them, instead of piling up complexity in either your DB design or constantly retraining developers in more advanced SQL approaches. Neither of those are cost effective in the long run.
|
|
|
|
|
I've been a developer DBA, for lack of an actual one DBA, and I can say that if you don't know how a database works, you won't perform well with EF either.
It's a real issue I think, developers forgetting they're talking to an actual database and not some in-memory code and data.
I check the generated SQL for all but the simplest queries (and I've become pretty good at predicting the generated SQL).
There are times when I think, this query is not going to scale very well, and I have to change my LINQ query to generate cleaner SQL.
Also, I do code first, but always check my migrations and how it's actually generated in the database.
I'm checking for names, types, foreign keys, etc.
It's very nice for DevOps and CI/CD though!
All in all, it's made my life a lot easier, but it doesn't take away that I need to know SQL or how a database works.
I've been able to ban views, functions and stored procedures from my life and fix it all in code with good and clean generated SQL queries 
|
|
|
|
|
I've never really like the migrations. I use a project/raw sql to generate and maintain my databases.
Phil
|
|
|
|
|
|
I've been using Entity Framework for about 10 years. Before that, I had 20 years experience in hand-coded SQL queries through stored procedures and views. So, I've used both approaches extensively. This is what I've found.
Against:
1) It occasionally produces poor-performing queries, especially when they are big
2) It consistently produces queries that are very hard to understand
For:
1) It saves a lot of time in the maintenance of stored procedures and views (or the ugliness of in-line SQL, if that's your thing)
2) You get compile-time checking. If I refactor my schema, my code breaks until I fix the problems.
Does it matter in my job?
Yes.
Does it positively or negatively affect database design or performance?
No affect on DB design - I design my database independently then hook EF up to that. It does have an affect on performance though in some cases. Generally, it's fine for simple CRUD operations, but where you have complex joins and grouping it can (but not necessarily will) produce slow queries. I'm generally pleasantly surprised by the perfomance. It produces crazy-looking queries with lots of sub-queries, but they seem to perform OK. I guess the EF designers know what SQL can handle.
My approach is to use EF where EF is fine, then drop into views/stored procs where necessary. The difficulty here is with inexperienced team members who may never get the opportunity to learn to hand-code SQL, so will just rely on EF when they shouldn't. Also, some developers just don't like the idea of mixing strategries and would prefer all or nothing.
Does its use ever cause you any headaches or make your job any easier?
Yes and yes!
The LINQ syntax can get very complex. Sometimes it's just quicker to write the SQL yourself. Occasionally queries need to be written in SQL for performance reasons. It all depends what you are doing really. If you are doing complex transactions on high volumes of data, then EF may not be the best choice for that.
The time saver isn't so much not having to write T-SQL, but on the admin overhead of having to write views/sprocs seperately from the rest of my code. The compile-time checking is the real benefit for me though. In the past, a common problem I had was production bugs due to an obscure view or sproc that wasn't updated after a schema change. Now, I have a limited number of views and sprocs to check, and the rest is caught by the compiler. This is the single biggest advantage for me. It's reduced production bugs and gives me a sense of safety to re-factor.
Cheers,
Carl
|
|
|
|
|
Make sure you understand navigation properties in EF before you go into production 🤯
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
