|
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 🤯
|
|
|
|
|
EF is an ORM at its core and must be approached as such.
Yes, we use it all the time and it matters greatly to my/our team's job.
If you design your database properly, then EF will work properly.
Most, not all, the EF haters have no clue how to use EF. So, they spout off nonsense about EF, but in reality, they know nothing about it or how to use it properly.
Good luck.
modified 28-Apr-21 6:27am.
|
|
|
|
|
One have to realize it's a tool. And all tools have to be used appropriately.
Just because it doesn't work for everybody doesn't mean it won't work for you. Or vice versa.
Performance: Yeah it's crap compared with ADO.Net, but you know what, in 95% of the cases you won't notice.
Pitfall nr 1: It doesn't remove you from having to understand how a database works.
It doesn't matter if you use Code First or Database First if you're anyway crap at modeling.
For the database I'm working on we have a data entry tool that uses EF. It has probably saved us a ton of time developing it.
For reporting we DON'T use EF. For performance reasons. Yes you can run queries directly in EF, but why add another layer if you're not going to benefit from that extra layer.
So my personal takeaway is that EF is fine for CRUD (and quite a bit more actually), but as soon as your queries are getting more advanced and aggregates a lot of data you need to watch out.
MSBassSinger wrote: Does its use ever cause you any headaches
Yeah, simple tasks as changing the datatype on a column isn't as easy as it should be if you're database first.
|
|
|
|
|
Just a point about what often seen as EF making very large queries for simple things.
If doing something like Get Record Where ID = 5
Quick SQL could be "select * from table where id = 5"
EF will use the full expanded out version, so that * becomes all the fields in the table.
So just like writing suitable SQL quieres, EF needs to be used appropriately. If just want to get 2 fields from a 20 field table, then in EF use .Select and Where in combination, and will generate out suitable query.
|
|
|
|
|
Most DBA's have no practical "application development" experience ... and their designs (and attitude) reflect that.
Asking a DBA about EF, or any ORM, would be like asking them what programming language to use.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
DBAs that are not application developers do have experience in dealing with poorly written SQL by application developers that they have to then clean up and optimize.
An application developer who uses SQLProfiler, is adept at SQL, understands indices, avoids table scans, etc. is a delight to the DBAs that have to manage the databases.
Asking them about EF and other ORMs is in the context of how does the application developer's use of them impact their work. And it does, if you read some of the other posts.
|
|
|
|
|
personally, I've used entity for a couple years, but stopped. I didn't like it, and have gone back to using stored procedures and then the system.Data namespace to use the calls, for multiple reasons:
*i don't need CRUD on all tables
*SPROCs are easy to test and verify results.
*complex joins and other like functions are easier to do in T-SQL before it gets to the app
*Entity framework feels heavy.
but these reasons are mine, and our environment works well with SPROCs.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
