N00b wanna learn more about database programming

Discussion in 'Programming & Software Development' started by xhanatos, Jul 9, 2007.

  1. Elyzion

    Elyzion Member

    Joined:
    Oct 27, 2004
    Messages:
    7,449
    Location:
    Singapore
    Sometimes i write sloppy code because i have a time frame to get it done in so i have to rush it. If i get to go at my own pace i always try to write it the best i can.
     
  2. hyperstyle

    hyperstyle Member

    Joined:
    May 24, 2003
    Messages:
    1,731
    Location:
    Brisbane
    I agree 100%. There is no other way to do it unless you're bad at your job.
     
  3. QuakeDude

    QuakeDude ooooh weeee ooooh

    Joined:
    Aug 4, 2004
    Messages:
    8,538
    Location:
    Melbourne
    You're not alone - there are plenty of companies that don't have dedicated Database developers. We use SQL as our backend for intranet applicatons, but there isn't enough work to warrant hiring a permanent SQL guy, so the work falls onto the developers themselves as a side task.

    Not ideal, but what do you do.
     
  4. GumbyNoTalent

    GumbyNoTalent Member

    Joined:
    Jan 8, 2003
    Messages:
    9,743
    Location:
    Briz Vegas
    OLD Skool UNIX on big iron.
     
  5. hyperstyle

    hyperstyle Member

    Joined:
    May 24, 2003
    Messages:
    1,731
    Location:
    Brisbane
    The main thing is a well designed architecture will save you time when you start adding all the bells and whistles. Not to mention that it's usually quicker to program good code than bad code. If time is pressed, write the sloppy code in the outer layers (maybe that's what you already do).
     
  6. Elyzion

    Elyzion Member

    Joined:
    Oct 27, 2004
    Messages:
    7,449
    Location:
    Singapore
    Well to give you an example.

    I had 1 day to write a Pay Per View system for our site. So i designed the database so i wouldn't have to change it later. Then wrote all the class's and stored procedures so i didn't have to change them later. But the actual click event for the site i wrote from top to bottom with a bunch of if statements. It achieved what i needed it to do.

    But it was hard to read and quite messy. About a week later when i got some free time i rewrote the entire click event so it was logical and easy to read and commented and cut the code down to about 1/5th the size.

    It didn't effect the business later or database. All i changed was the code behind.

    I hope that makes sense.
     
  7. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,041
    Location:
    Sydney

    how can you optimise for things that havent even been conceptualised?
    have your requirements never changed in a long term product ?
    what if the project grows 10x you will have to optimise!
     
  8. Bradzac

    Bradzac Member

    Joined:
    Aug 17, 2003
    Messages:
    1,744
    That in no way makes him a bad developer, that makes him a developer who uses a different software development methodology then you and his "Do not optimize early" statement is with good reason and practised and sworn by good developers worldwide. Don't be ignorant. Just because your style works well for your company, does not mean it will work for the next.
     
  9. hyperstyle

    hyperstyle Member

    Joined:
    May 24, 2003
    Messages:
    1,731
    Location:
    Brisbane
    Proper planning. If the client says we need to allow for growth to x5 times (they probably think they are overly cautious). Plan the architecture to cope with a growth of x20. That doesn't mean you have to implement and utilise the services from day dot that application will use when it grows bigger but allow for easy plugging in. That way you don't waste time early on when the client wants to see results and unwilling to fund the development of a flushed out architecture that they can not see.
     
  10. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,041
    Location:
    Sydney
    i never said optimisation results in inefficient code, i said in results in increased complexity and reduced maintainability.

    for example, converting an ArrayList of into a short[] . It is more efficient performance wise but requires more code and increases complexity thus reducing maintainability.
     
  11. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,041
    Location:
    Sydney
    and what happens when the client needs x100 or x1000? has this never happened to you?
     
  12. Bradzac

    Bradzac Member

    Joined:
    Aug 17, 2003
    Messages:
    1,744
    Use a generic list instead of ArrayList ;)

    List<short> shortList = new List<short>();
     
  13. hyperstyle

    hyperstyle Member

    Joined:
    May 24, 2003
    Messages:
    1,731
    Location:
    Brisbane
    Sure it has. But if that's the case the problem isn't really an optimisation problem. It's an architectural problem. What happens there is you do a restructure at the x20 mark and plan for the 100x - 1000x growth.
     
  14. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,041
    Location:
    Sydney
    i knew that was coming as soon as i hit send hehe

    doesnt change my point.
     
  15. Luke212

    Luke212 Member

    Joined:
    Feb 26, 2003
    Messages:
    10,041
    Location:
    Sydney
    If it takes 5 hours to write a() for 100 requests, and 10 hours to write a() for 100 000 requests, the manager would have told the programmer to do it for 100 requests, because that is the max estimated.

    now later a new module uses a() 100 000 times a sec. a() becomes more important and is optimised accordingly.

    is that fair?
     
  16. GumbyNoTalent

    GumbyNoTalent Member

    Joined:
    Jan 8, 2003
    Messages:
    9,743
    Location:
    Briz Vegas
    After 22 years here is what I've learned.

    1. Code will never be perfect but if it works as expected without error than it is perfect for the job.

    2. Good standards are a must, good documentation is usually optional, document your code.

    3. The user/client will always change their mind, be more proactive with them. SCRUM AGILE XP whatever it is this week. And be prepared for it.

    4. User/Client doesn't care about the technical wankery behind the scene all they care about is that it works for the price and in the time frame requested.

    5. YOUR CODE WILL HAVE BUGS live with it nobodys perfect, including QA.

    NB

    6. NEVER FIX WHAT ISN'T BROKEN! because the next thing to break will be your fault regardless.
     
  17. hyperstyle

    hyperstyle Member

    Joined:
    May 24, 2003
    Messages:
    1,731
    Location:
    Brisbane
    That would be called optimising. But I was originally taking about the program architecture and that's what you quoted me on. Optimising the core of your application is a very hard thing to do and shouldn't have to be done if you did proper planning.
     
  18. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    No. Stored procedures are not an optimisation technique. They can be faster but the choice of using them should not be for the sake of performance but for the sake of isolating code that only involves manipulating data in the local database. You don't lose maintainability by using stored procedures and you certainly don't improve it by pushing everything outside into a higher layer.

    You missed the point. Your instinct to avoid early optimisation is correct; your application of that principle is not.

    A correctly architected system is not an optimisation but a quality solution. Putting stuff where it belongs (in this case, the database and not in classes) is also sound software engineering practice. Messing all of that up for the sake of perceived simplicity in a system that is not a throwaway prototype is wrong. Your code is no less readable or understandable if you layer it properly. Premature optimisation would be (for example) de-normalising your database for speed before you've finished nailing down what you're storing.
     
    Last edited: Jul 18, 2007
  19. Ze.

    Ze. Member

    Joined:
    Sep 13, 2003
    Messages:
    7,871
    Location:
    Newcastle, NSW
    I still stand by the fact that it's a stupid rule for stupid developers because it ignores the experience and knowledge developers have in analysis,design and development.

    A developer should use his knowledge and experience to decide upon the right level of optimisation at the right stages of the project and not leave it till the end. That is how we end up with projects that don't meet the requirements.

    The logical fallacy that good code isn't optimised ignores this. There are many aspects to good code and we could argue all day about what's good code and what's not. In the end it can often depend up the project.

    I know my view of good code has changed over the years.

    The reason in most why they end up with more unreadable code is because they are trying to tack it onto the solution instead of designing the solution with it from the start based upon their experience and the project requirements.

    The golden rule of software is as a codebase gets more and more tacked onto it gets less maintainable. So in a sense it's really a self fulfilling rule.

    We could go on about this forever but ultimately optimisation should be going in one through ones head right from the start of the design phase , there will be optimisations that are appropriate there and there will be ones that may never be implemented and decisions to be made in favour of when,where and how to implement optimisation. Some decisions will make optimisation later harder , some will make it easier and sometimes you'll do it at that point.

    Sometimes optimisation is just choosing the appropriate class for the job. Sometimes it's more complex but often it can result in a simpler and faster codebase. Just by knowing the right tool for the job.

    In the end the principle implement first optimise later is foolish and inefficient. Why implement the solution twice when relying on experience , knowledge and project constraints first can allow you to get it right the first time?
    Who is he? I probably know him :p

    mordy annoys me because of the crap he posts , I wouldn't mind his posts if he actually wanted to learn. The day I die is the day I stop learning.
    The main reason for that is that java has a templating system which is a hack and relies on dynamic casts underneath , it's good in some areas but should've been done differently from a performance viewpoint.
    Does that even work in java? Since List is an interface?
     
  20. Elyzion

    Elyzion Member

    Joined:
    Oct 27, 2004
    Messages:
    7,449
    Location:
    Singapore
    It's the new Generics in .net 2.0 AFAIK. I think it's useless for pulling collections from a database. I got it working but it ended up making things more complicated and less logical IMO so i went back to using a CollectionBase.
     

Share This Page

Advertisement: