Comment On Enterprise SQL

In yesterday's post (Bitten by the Enterprise Bug), we learned how vital enterprise application are for proactive organizations leveraging collective synergy to think outside the box and formulate their key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. But of course, that's all a "high level" overview of things. Today, I'd like to dig into the code of enterprise systems a bit. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5Next »

Re: Enterprise SQL

2006-05-04 13:22 • by Stoneman
71183 in reply to 64846

Hey just to let you know! I used to run a 5000 user system on hardware just above 486's!!! and they fastest performance came about by putting as much logic as possible in the stored procedures!!!

So anyone that tells you this is bad!  needs to come back to reality They are the same people that say 5th normal form is the way to go!!! hahaha when in the real world most people run 3rd normal form so they can "USE" their database!


Anyway I highly recommend putting logic in the stored proc's if speed is your holy grail!

Re: Enterprise SQL

2006-07-13 12:45 • by Scrub

I could somehow see that making constants for table names and possibly column names could have a purpose, but it takes away readability and makes it so much harder to alter the SQL in the code. Think about it, if you need to proof read or test run this SQL in the database.

If you use bind variables (which you almost always do except when it is blatantly obvious that the parameters never change) 'select *... ' will break your prepared statements, you will have to restart the application to add a column

The SqlMisc.PARAMS_FIRST, SqlMisc.PARAMS_SECOND probably comes from Oracles older syntax where you could name the bind parameters :1, :2 etc



Re: Enterprise SQL

2007-02-11 01:42 • by Narendra Venkataraman (unregistered)
Very true.. In fact I was planning on writing on "Parody of constants" but this is too good.. some more enterprisocities like coffee talks -

Re: Enterprise SQL

2007-02-12 10:35 • by Jonadab (unregistered)
119428 in reply to 64846
For some reason or another, I've worked with many DBA's in the past that absolutely forbid the use of stored procedures, views, triggers, etc (basically anything besides tables and indexes). Basically, the argument is that once you start doing that, you're starting to embed application logic in the database.

I am against putting application logic in the database, which is the only thing I've ever seen stored procedures used for. In the case I'm thinking of, 25+ pages of seriously inscrutable SQL performed what would have been less than 20 lines of code in pretty much any high-level language. Because of the wrong-headed design, which apparently used triggers just to demonstrate that the programmer knew how, various things had to be coded in SQL up to three times: once in the stored procedure that runs nightly as a job, again in the stored procedure that the trigger calls, and again in the one that is called in response to a user action at some later time. Another time I found stored procedure code created, propagated, and iterated over entire temporary tables that were strictly necessary, making for 5+ pages of stored procedure, which when refactored came to less than 1 page of SQL, let alone what it would have been in a high-level language.

And this wasn't even really in an enterprise product, just a garden variety dubiously-implemented one.

I don't know that I would categorically forbid stored procedures, but I would certainly discourage gratuitous overuse of them.

Re: Enterprise SQL

2007-06-22 04:54 • by rdrunner
142152 in reply to 65056
So you're saying that if the vendor simply implemented a brand new type of object whose purpose was specifically to reduce index-to-table lookups, then it would all be fine because "that's what it's supposed to do"?  The only reason this is a hack is that they are called "indexes"?  That goes back to a "the world revolves around me" position.  You don't like covering indexes because they aren't "right".
Here is an interesting analogy:
Indexes are called "indexes" because they work like the indexes in these things we call "books".  Well, a typical book index contains a keyword and a page number.  If you were looking for how many pages reference the word "widget" in a given book, you could entirely answer that question from the index.  Hey, look, database servers do that too!!!!  Covering indexes don't abuse the abstract concept, the concept of covering indexes has been in books for hundreds of years.

Actually there is a new feature in SQL2005 that allows you to explicitly include columns into an index (Those new columns will be added to the leaf nodes of the index, so you can save some performance, since the extra Columns dont have to be sorted)

To create a covering index, you need to know how you DB is used. Its not something you do light hearted. If you have a wide table, and you often retrieve only a very small subset of columns, then its a perfect solution. Yes, it creates some aditional overhead when you modify your data, but the net result can be quite effective.


And it is by NO WAY a "hack"

Re: Enterprise SQL

2009-01-07 04:26 • by Ömer Faruk Z (unregistered)
where is the enterprise sql?

cheap g-star jeans

2009-07-20 15:28 • by cheap g-star jeans (unregistered)
277131 in reply to 65039
<a href=>cheap g-star jeans</a> <a href=>cheap guild wars gold</a> <a href=>cheap guild wars gold</a> <a href=>cheap handbags</a> <a href=>cheap handbags</a> <a href=>Cheap handbags</a> <a href=>cheap jeans</a> <a href=>cheap Jordan</a> <a href=>cheap Jordan</a> <a href=>cheap jordan shoes</a>


2009-07-21 16:34 • by �������Ƿ�Ⱦ (unregistered)
277550 in reply to 65039
�й�<a href=>�������Ƿ�Ⱦ</a>���Ǵ������Ƿ�Ⱦ��ҵ�Ĵ������Ƿ�Ⱦ�ƹ㡢�������Ƿ�Ⱦ�ɹ����������Ƿ�Ⱦ�������������Ƿ�Ⱦ��չ���������Ƿ�Ⱦ�б���ҵƽ̨��ɽ����<a href=>�������и�</a>����. ��ɽ�������и�����. ��ɽ�������и�����. ��ɽ�������и���˾���� �й�<a href=>��������ô����</a>�������ۺ��ԵĴ�������ô������ҵ��վ,�����Դ�������ô����ý�顢��������ô���ƴ��⡢��������ô�����г��ȴ�������ô�������ºʹ�������ô����������<a href=>������תС����</a>��˾-��������魴�����תС�����˾���׶�����׿���Ĵ�����תС�����˾,��������תС�����˾�ṩ50������ֵĴ�����תС�������.<a href=>��ѧ����</a>��˾�Ľܳ����������Ϻ���ѧ���й�˾���й���������Դ�ѧ���з����ṩ�̣������ѧ���й�˾����ǿ���ѧ������Դ��ͨ<a href=>��բз</a>]��˾���ൺ֪���Ĵ�բз��˾,�ൺ��բз,�ൺ��բз��ƹ�˾,�ൺ��բз����й�<a href=>�������</a>���Ǵ��������ҵ�Ĵ�������ƹ㡢������˲ɹ���������˼�����������˻�չ����������б���ҵƽ̨�����ش���Ҫ�š�<a href=>����</a>��֪�͵��ش������¸�ʾ��

Cartier jewelry

2009-07-22 00:24 • by Cartier jewelry (unregistered)
277730 in reply to 65039
<a href=>Cartier jewelry</a> <a href=>cell phone for sale</a> <a href=>cell phone wholesale</a> <a href=>centrifugal fan</a> <a href=>centrifugal fan</a> <a href=>ceramic Rollers</a> <a href=>CFD</a> <a href=>CFD</a> <a href=>CFD</a> <a href=>CFD</a>


2009-07-23 11:57 • by ���̲߻� (unregistered)
278917 in reply to 65039
<a href=>���̲߻�</a> <a href=>�նȼ�</a> <a href=>������</a> <a href=>������</a> <a href=>�����</a> <a href=>���ְҵ��������ѵ</a> <a href=>�㽭EMBA</a> <a href=>�㽭��ѧEMBA</a> <a href=>�㽭��ѧMBA</a> <a href=>�㽭���׹���</a>


2009-07-25 02:00 • by �¾���Ѫ�������� (unregistered)
279443 in reply to 65039
����ȥ�¾���Ѫ����������Ϊ���ṩ����ʵ��<a href=>�¾���Ѫ��������</a>������ܡ��¾���Ѫ���������������С������¾���Ѫ���������¾���Ѫ�������������·���¾���Ѫ����������������·���¾���Ѫ�������𾰵�·�߹��ԣ��л��¾����ڼ������л���ս�Ժ��������;<a href=>�¾����ڼ���</a>��ȫ����Ӫ���ṩ�¾����ڼ�����·��ѯ����ȫ��λ�¾����ڼ�������Լ���Ȩ�����¾����ڼ�����Ѷ��Ϣ���ְ�˹<a href=>�¾�������ô��</a>,�����¾�������ô��,�¾�������ô�����,ƽ���¾�������ô��,�����¾�������ô��,��Ц�¾�������ô��,�����¾�������ô��,���<a href=>�¾������Ƴټ���</a>�������¾������Ƴټ�����������¾������Ƴټ��췢������¾������Ƴټ���IJĵ������Ѷ.����<a href=>��ɩ</a>��˾,רҵ������ɩ��˾,�Ϻ�����ʱ����ɩ��˾Ϊ���ṩרҵ������ɩ,�������������ͬ��ɩ���<a href=>Կ�׸��ƻ�</a>�����ṩ������Կ�׸��ƻ����߲��ź�Կ�׸��ƻ���Կ�׸��ƻ���רҵ����ƵԿ�׸��ƻ���վ���Ϻ�<a href=>�и�����</a>Ϊרҵ�и�������˾���и�����������Ϊרҵ���и�������˾֮һ�����ɹ��и�С�����Ż���վ,<a href=>�и�С����</a>���ɹ��������и�С����Ƶ��,�и�С���������������.


2009-07-25 10:02 • by ��Ĥ�컨 (unregistered)
279517 in reply to 65039
<a href=>��Ĥ�컨</a> <a href=>��ľ��</a> <a href=>������</a> <a href=>��ʿ�ֱ�</a> <a href=>�������</a> <a href=>��Ͽ</a> <a href=>��Ͽ����</a> <a href=>��Ҷ�޴ķ��</a> <a href=>��Ҷ�޴Ĺķ��</a> <a href=>ɢ��Ƭ</a>


2009-07-25 13:20 • by ��ǻ������ (unregistered)
279546 in reply to 65039
<a href=>��ǻ������</a> <a href=>��ǻճ��</a> <a href=>Ƥ���������</a> <a href=>Ƥ���</a> <a href=>Ƥ������</a> <a href=>Ƥ��</a> <a href=>����</a> <a href=>Ƭ״ģ����</a> <a href=>ƫ����΢��</a> <a href=>Ƶ�׷�����</a>


2010-03-31 12:03 • by ��ְ�о����������� (unregistered)
304162 in reply to 65039
��������ְ�о�������������,<a href=>��ְ�о�����������</a>�Żݣ��������㣬��ְ�о�������������·�������Σ������μǣ�������ְ�о���������������ϢΪ�����ܽ�����ְ�о�������,�Ͼ�<a href=>��ְ�о�������</a>,,��ְ�о������԰����ȷ���Ϊ����ְ�о��������Ͼ��ṩ�Ͼ���ְ�о������Ծ�����Ͼ���ְ�о���������·�����Ĵ���ְ�о������ṩ��ɫרҵ���Ĵ�<a href=>��ְ�о�����</a>,��կ����,�ɶ�,��կ����ְ�о�����,����,��üɽ,��ɽ,������ְ�о�����������Ϣ��ְ�о�������,������,<a href=>��ְ�о�������</a>��,�й���ְ�о��������Ż���վ���ṩ��ְ�о�����������ְ�о��������������棬��ְ�о���������ȫ��������ְ�о����������й��������ڸ�Ӳ���ļ�飬���ڸ�Ӳ���ļ��Ƶ��������ʡ�������ڸ�Ӳ���ļ����Ϣ��Ѷƽ̨����������ȫ���ڸ�Ӳ���ļ�����µ����ڸ�Ӳ���ļ����Ѷ


2010-04-09 09:34 • by ϴ�س� (unregistered)
305208 in reply to 65039
�й��Ļ�ϴ�س�������̽���й�<a href=�Զ�.html>ϴ�س�</a>�������й��Ļ����й�ϴ�س������ṩ��Ӧ��ϴ�س��Ӵ�����ϴ�س���Ʒ��ϴ�س���ѯ����ϴ�س��Ż������<a href=>ϴ�س�</a>�����Ժ������ҽ�Ŀ���ṩϴ�س���·��ѯ��רҵȨ����ϴ�س���Ѷ��Ϣ������ϴ�س����ϴ�س��Ż�<a href=�Զ�ˢ��_ϴ�ػ����.html>ϴ�ػ�</a>ר������Ȩ����ϴ�ػ�ר����ϴ�ػ�ר��Ϊ����ѡ��ϴ�ػ���Ʒ��ӭ����չʾ����ϴ�ػ���Ʒ<a href=>ϴ�ػ�</a>��˾-���������ϴ�ػ���˾���׶�����׿����ϴ�ػ���˾,��ϴ�ػ���˾�ṩ50������ֵ�ϴ�ػ�����.ϴ��������,����<a href=>ϴ������</a>,���ϻ���ϴ������,����ϴ�����칫˾��ϴ������߻�����,ϴ�����취�ɷ���,ϴ����������

Re: Enterprise SQL

2010-04-25 16:13 • by Jim McMaster (unregistered)
This is not a new phenomenon. I worked in IBM 370 Assembler language for several years. My company decreed you had to define constants for everything. There was a constant for "the number of bits in a byte." Apparently, if IBM ever changed, we could just rebuild and continue.

Re: Enterprise SQL

2010-10-18 10:00 • by ship (unregistered)
It's really silly approach!
I can e.g. say, that next generation of Java will completely use different definition of constants...
I'm really curious how much time u would spend by refactoring your Java code to allign this changes with...

Re: Enterprise SQL

2012-03-20 05:38 • by Frosty (unregistered)
I've met an incredible enterprisey guy.
See his work:
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5Next »

Add Comment