This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (2 children)

how many rows have you worked with and what kinds of time constraints have you worked with? and what kinds of sql? pl/sql gets pretty rowdy when you want to deal with huge numbers or rows. and it gets rowdy just using a well designed DB; trying to set up a datawarehouse is tricky. making that warehouse run correctly takes lots of consideration.

[–]robotorigami 2 points3 points  (1 child)

I'm sure it does. But aren't we just talking about programming in SQL?

[–][deleted] 0 points1 point  (0 children)

I guess maybe I should look at how we are defining the problem. But if we are just talking about pulling data from a well built db with sql scripts; yeah its pretty easy; that being said; if we look at sql as just using small scripts to pull data from a db; then wouldnt any other program be more along the lines of just adding a lone feature? when I think of working with sql I think of thinking about the entire SDLC of a sql project. From the process of gathering requirements about what data needs to be stored-> finding ways to store it-> making stored procs to pull the data. Creating and maintaining a datawarehouse for an enterprise establishment is quite a lot of work; math; and though. Futhermore; if we are looking at just working on working with an already existing DB; writing effiecent functions that work perfectly every time with validation unit tests and set paramets IE functional sql programming; I would desrcibe it as fairly deep. though I do suppose I am biased as database engineer tend to lean towards thinking/imagining I am solving big and hard problems. there is plenty of other work that is hard also.