Instead of simply recommending that you sodomize yourself with a retractable baton, let me recommend a specific model - the ASP 21". The previous lawyers tried to use a cheaper brand, but it broke during the action.
Automate the repetitive parts, like the code that wraps a stored procedure into a language specific call (If you have lots of stored procedures), and maybe some of the UI if it follows a very clear pattern (which you find after writing the same thing with a number of variants, like the number and type of fields in a record).
You can also generate automated tests for the generated code, to test for build consistency, etc.
Avoid writing your own database access layer and use a proven o/r mapper like hibernate, it simplifies your life incredibly. Note that for some operations you still need to write stored procedures (bulk processing).
Writing your own code generator very, very fun and a great learning experience but chances are there is something better out there that already works, remember that you are writing an application not a code generator.
If it's an area you don't have a lot of experience with, estimating can be very hard. Do some research but be prepared to do it the conventional way if time is a limiting factor.
- Look for an external company that is dedicated IT support outsourcing (local, so they can be on site if needed). - Invite them and ask them for a proposal to replace your current IT dept in some functions (make sure to get respose times and costs). - Show them to senior management, an ask internal IT to make a counter offer.
IT needs to start treating you like a customer, not like a problem that needs to be dealt with.
The arguments the church usually makes is if that you look at the human eye, it is so perfect and peculiar it could have only been designed by an intelligent being.
The argument opposing it is that the human eye has multiple defects (easily dechachable cornea and a blind spot) and an all-knowing perfect entity would have never commited those mistakes. Also the octopus eye is given as an example of a better design.
Stored procedures are a performance optimization, consider the following scenario:
Retrieve the 20th page using a page size of 50 records for all the SKUs under a catalog (potentially millions total) for a specific user which could or not have visibility permissions for each SKU. Assume the security provided by the database is too coarse to fulfill the business requirements, therefore some set of rules must be evaluated to determine SKU visibility for a particular user.
That query would normally be very fast if implemented as a stored procedure because: 1) Only one round-trip is needed. 2) You don't have to move all the data to a middle-tier and then filter out information. 3) RDBMSes are usually faster at filtering data out (by using indexes, denormalization, etc.) that what a developer could code in a middle-tier to filter out information. 4) Most RDBMSes are very good at scheduling tasks, caching, managing memory, etc. The more you move logic away from it, the more you would have to implement it yourself.
You could send all the SQL statements to the database and achieve the same effect, but it might make debugging harder and you still have all the SQL logic in some place, only a different one.
On the flip side: 1) It's harder to write stored procedures than it is to write code in a managed language like Java or C# (thirty-line SELECT statements are not very intuitive). 2) Generally speaking, the compiler of a managed language does a better job at catching errors than a compiler for stored procedures, where a lot of the errors will be caught at runtime. 3) Stored procedures are not portable.
My advice is, if you are only using the RDBMS as a persistence device and your data size is not huge, avoid stored procedures and create some sort of middle-tier object model. Only when performance is a impediment, use stored procedures. You might as well use a hybrid approach, try to model as much as you can in the middle-tier and implement stored procedures for those tasks which are performance intensive.
I work with people that worship UML and patterns as well with RDBMS Gods that can plow through pages and pages of stored procedures without blinking. As much as I love ULM and patterns there are some tasks that must be done in the RDBMS for performance reasons, and tasks that are simply more maintainable when done in the middle-tier. Both approaches have advantages and disadvantages, the trick is to use the best approach according to the situation.
Just after getting a brand new ThinkPad, I accidentally emptied a full pint of Guinness over the keyboard. After removing the battery, I dried all I could with a towel. I thought it had gone POOF! I was already thinking of how to explain the incident to my new employer.
Twenty minutes later I put the battery in and to my surprise it worked perfectly, apparently the IBM engineers placed a metal plate to protect the internals from this type of hazard.
The only side effect was a strange sound when tapping some keys; I think some amount of dry beer is still inside there.
Ohh...and I once overwrote the only copy of a friend's thesis. He was using a single floppy and I needed a boot disk.
Slashdot Mirror
Depends on how ugly the alien is.
Its a great example of a conflict of interest.
http://en.wikipedia.org/wiki/Conflict_of_interest
It would blow
Read on:
Instead of simply recommending that you sodomize yourself with a
retractable baton, let me recommend a specific model - the ASP 21". The
previous lawyers tried to use a cheaper brand, but it broke during the
action.
Automate the repetitive parts, like the code that wraps a stored procedure into a language specific call (If you have lots of stored procedures), and maybe some of the UI if it follows a very clear pattern (which you find after writing the same thing with a number of variants, like the number and type of fields in a record).
You can also generate automated tests for the generated code, to test for build consistency, etc.
Avoid writing your own database access layer and use a proven o/r mapper like hibernate, it simplifies your life incredibly. Note that for some operations you still need to write stored procedures (bulk processing).
Writing your own code generator very, very fun and a great learning experience but chances are there is something better out there that already works, remember that you are writing an application not a code generator.
If it's an area you don't have a lot of experience with, estimating can be very hard. Do some research but be prepared to do it the conventional way if time is a limiting factor.
Why mod parent down? It makes an interesting point.
- Look for an external company that is dedicated IT support outsourcing (local, so they can be on site if needed).
- Invite them and ask them for a proposal to replace your current IT dept in some functions (make sure to get respose times and costs).
- Show them to senior management, an ask internal IT to make a counter offer.
IT needs to start treating you like a customer, not like a problem that needs to be dealt with.
Christian researchers corrected:
"Researchers Say Human Brain is Still being intelligently designed."
"will it determine if the woman I am about to marry will turn into a mad cow down the track.... now that would truely be a useful test."
Look at her mom.
They should mention that if you want to use those you need Windows XP. I'm still using Windows 2000 and I don't plan to upgrade the OS for a mouse.
It uses Doom3 technology and you need your mouse over anything you actually want to see.
I will tell you the real...ughhhh!! *dies from a poiton dart*
When given pen and paper, it wrote down:
"Developers, developers, developers!!!!"
"Whether it's theft of service, or theft of property, it's still theft."
It's called copyright infringement.
If you're referring to 2000 Fox wasn't the first to call it. THat's another F911 fabrication.
Care to backup your statement? Moore does provide some information on his assertion.
The arguments the church usually makes is if that you look at the human eye, it is so perfect and peculiar it could have only been designed by an intelligent being.
The argument opposing it is that the human eye has multiple defects (easily dechachable cornea and a blind spot) and an all-knowing perfect entity would have never commited those mistakes. Also the octopus eye is given as an example of a better design.
They should be able to get the standard 25fps for movies with their current hardware, but it will look very pixelated
Stick to mobs weak to heat and bring a lot of power potions.
"clever idea's about how to deal with it including one which disposes of it in the giant fusion reaction that is our Sun"
What if we miss and it hits the earth the day after?
Linux doesn't exist. Everyone knows Linux is an unlicensed version of Unix
-1 Troll
Or this
This one has a very long battery life and it reboots FAST.
Stored procedures are a performance optimization, consider the following scenario:
Retrieve the 20th page using a page size of 50 records for all the SKUs under a catalog (potentially millions total) for a specific user which could or not have visibility permissions for each SKU. Assume the security provided by the database is too coarse to fulfill the business requirements, therefore some set of rules must be evaluated to determine SKU visibility for a particular user.
That query would normally be very fast if implemented as a stored procedure because:
1) Only one round-trip is needed.
2) You don't have to move all the data to a middle-tier and then filter out information.
3) RDBMSes are usually faster at filtering data out (by using indexes, denormalization, etc.) that what a developer could code in a middle-tier to filter out information.
4) Most RDBMSes are very good at scheduling tasks, caching, managing memory, etc. The more you move logic away from it, the more you would have to implement it yourself.
You could send all the SQL statements to the database and achieve the same effect, but it might make debugging harder and you still have all the SQL logic in some place, only a different one.
On the flip side:
1) It's harder to write stored procedures than it is to write code in a managed language like Java or C# (thirty-line SELECT statements are not very intuitive).
2) Generally speaking, the compiler of a managed language does a better job at catching errors than a compiler for stored procedures, where a lot of the errors will be caught at runtime.
3) Stored procedures are not portable.
My advice is, if you are only using the RDBMS as a persistence device and your data size is not huge, avoid stored procedures and create some sort of middle-tier object model. Only when performance is a impediment, use stored procedures. You might as well use a hybrid approach, try to model as much as you can in the middle-tier and implement stored procedures for those tasks which are performance intensive.
I work with people that worship UML and patterns as well with RDBMS Gods that can plow through pages and pages of stored procedures without blinking. As much as I love ULM and patterns there are some tasks that must be done in the RDBMS for performance reasons, and tasks that are simply more maintainable when done in the middle-tier. Both approaches have advantages and disadvantages, the trick is to use the best approach according to the situation.
Just after getting a brand new ThinkPad, I accidentally emptied a full pint of Guinness over the keyboard. After removing the battery, I dried all I could with a towel. I thought it had gone POOF! I was already thinking of how to explain the incident to my new employer.
Twenty minutes later I put the battery in and to my surprise it worked perfectly, apparently the IBM engineers placed a metal plate to protect the internals from this type of hazard.
The only side effect was a strange sound when tapping some keys; I think some amount of dry beer is still inside there.
Ohh...and I once overwrote the only copy of a friend's thesis. He was using a single floppy and I needed a boot disk.
You might want to post that question in another website :)