Why do Dev people go on holiday?!!??

  • Greetings fellow MS racketeers,

    Our lovely Dev lady is sunning herself in the Maldives, and while she's topping up her tan, her workload is topping out in my Inbox.  This is the latest email to hit me...I have next to NO dealings with code-writing, but here it is.  It doesn't look that difficult, but I simply have too many Admin issues right now to deal with.  Here's the spec in bold text from the vendor, seems easy, but like I said, I just can't spare the time;

    1. Create an Employee table. Including columns:- first name; last name; length of service; daily rate; date joined; address; employee id; Date of Birth; Title; sex; Job Description

    2. Create a Project table having columns:- Project Name; Company; Task; Manager id; Cost; Time spent; Employee id; Charge rate; Project id

    3) Business rules - there may be only one employee per task, 1+ tasks per project, and 1+ projects per company

    3. Ensure all columns have primary and foreign keys, and report whether any non-atomic values will exist in the tables.

    Now, I don't know what the heck a 'non-atomic value' is; but nothwithstanding, my gut tells me there's a better way yet to store this data, any ideas?  Also, judging from office buzz, I'm vaguely aware of previous front-end issues regarding excessive 'derived data', am I right in thinking that the only instance of this will be the 'Cost' field?

    4. We will advise of the views needed shortly.

    5. Reports runnable      

    1) Total cost to date for each programmer to date.

    2). First and last names, project name and total cost, grouped by first letter of surnames.

    I understand this will entail a list of all employees whose name begins with a given letter, so a copy of the result set for 'C' is sent to a department dealing with employees from 'A' to 'G', and I change the letter on an as-needed basis.

    3. Query the above tables to show all managers.

    I presume this would simply be a Select 'First_name', 'Last_name' from the emp table Where 'Job_Description = 'manager'.

     

    Thanks in advance for your help,

     

    Jay.

  • Let us suppose that project A had a task called documentations and project B had a task called documentation. In a projects and employees schema these would be non-atomic.

    If you had a tasks table then there would only be one "documentation" task.

    It's worth would be infinitely underestimated and its cost grossly overestimated.

  • Sounds more like homework than a request from the vendor...

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • You sure this is not some school assignemt your dont really feel like spending the time doing yourself ?

     

     

    Hope this helps...

    Ford Fairlane
    Rock and Roll Detective

  • Personally, having had a lot of experience of third party database product vendors, I'd request them to write it. If it's their system, running on top of their database design, then if you create an object which isn't exactly what they want, it gives them ammunition in the future to blame you for problems that really sit with them.

    I don't like to sound so cynical, but experience tells me that self preservation of one's sanity should be your priority here. A professional lifetime of receiving emailed 'SQL Server' scripts from big software houses which are actually written and tested on Oracle or DB2, and have never been tested on our beloved database platform, and will never, ever compile on it tells me this is the best option ! 


    Jon

  • Appreciate the help, the advice, and even the cynicism!

    I've indeed put this ball back into the vendors court, having read the finer print of our SLA.

    Thanks again,

     

    Jay.

  • Very wise on your part. Just always remember this:

    When you read the fine print you'll adquire knowledge, when you don't you will adquire experience

     

     


    * Noel

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply