Re: Entity Framework opinions

From: Karth Panchan <keyantech_at_gmail.com>
Date: Wed, 18 Dec 2013 06:24:23 -0500
Message-Id: <CE6B850B-468C-47D3-BF66-FD4124C09E08_at_gmail.com>



I second D'Hooge.

Also having code in framework instead of Database will need application outage if there is minor change required to SQL.

HTH Karth

> On Dec 18, 2013, at 3:19 AM, D'Hooge Freek <Freek.DHooge_at_uptime.be> wrote:
>
> Hi,
>
> I have no experience with this particular product, but in my opinion there are some general things to be concerned about with this type of frameworks.
>
> database agnostic
> probably this framework works for every database and does not care or now about the differences in how different dabase brands (or even versions) work in respect to locking / cbo / datatypes ...
>
> no optimizing
> As all sql is generated, you can't change the sql statements to tune them by rewriting them in a different way or by adding hints
> the tuning pack can be of aid here to setup sql profiles to force a particular execution plan.
>
> developers don't know about the table structures anymore
> With Hibernate I often see that the developers are combining objects, resulting in queries that are unnecessary complex and involve tables that are, in the end, not required for the result.
> In your case, using the stored procedures, the front-end developers might also not be aware of the table structures, but the developers building the procedures are a(and they control the flow).
>
> security / re-usability
> By using a separate pl/sql package procedure layer between the application and the database (in different schema's) you are using a kind of "controlled" port to the db. Allowing you to steer the data flow and the db user used by the application to login to the db does not need to have full access to the tables / views. Just execution privileges on the packages.
> These packages can also be re-used by other applications (or different front-ends) that need to access the same database.
>
>
> The points above may or may not be applicable to this particular product, but my personal feeling is that with these kinds of products, everything gained at the developers side will cost you double in the dba side afterwards.
>
>
> Kind regards,
>
> --
> Freek D'Hooge
> Uptime
> Oracle Database Administrator
> email: freek.dhooge_at_uptime.be
> tel +32(03) 451 23 82
> http://www.uptime.be
>
>
>
>

>> On wo, 2013-12-18 at 06:58 +0000, backseatdba_at_gmail.com wrote:
>> I am looking for DBA’s opinions on Microsoft Entity Framework.  It lets the developers write programs that interact with the database with out having to write any database code, the framework does it for them.  The way we currently write programs is that all database code comes from a procedure, function, etc.  Entity Framework can bypass that and allow them to select,insert,update,delete without any procedures.  It is nice for them because it is quicker development and I looked at some of the queries it developed and they seem pretty efficient.  We haven’t started using it but I want to see if any other shops are using it and is good or bad for the database?  Is there any thing as a DBA I should be concerned about?
>> Thanks,
>> Jeff

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Dec 18 2013 - 12:24:23 CET

Original text of this message