Forum Replies Created

Viewing 15 posts - 1 through 15 (of 70 total)

  • RE: Table-based Functions vs. Views

    Lynn Pettis (5/9/2012)


    Do your stored procedures filter the data from the views based on values based to the stored procedures, and only return the columns needed for that call?

    If so,...

  • RE: Table-based Functions vs. Views

    SQLKnowItAll (5/9/2012)


    Putts (5/9/2012)


    SQLKnowItAll (5/9/2012)


    You can use 1 SP built to handle all 3 of those scenarios and then no views, no functions, and you only change 1 SP. 1 SP...

  • RE: Table-based Functions vs. Views

    DiverKas (5/9/2012)


    Woah. Why can't you rely on a SP returning all necessary columns? Thats how you write it. Its simple CRUD. For example, typical...

  • RE: Table-based Functions vs. Views

    SQLKnowItAll (5/9/2012)


    But, you are not going for optimization with your view. You are using it to simplify your coding process. So the above article is a moot point to...

  • RE: Table-based Functions vs. Views

    SQLKnowItAll (5/9/2012)


    You can use 1 SP built to handle all 3 of those scenarios and then no views, no functions, and you only change 1 SP. 1 SP per class.

    ......

  • RE: Table-based Functions vs. Views

    DiverKas (5/9/2012)


    The issue I see, is your trying to create this abstract layer IN the SQL Server, instead of in your data access layer. I understand your goal, but...

  • RE: Table-based Functions vs. Views

    SQLKnowItAll (5/9/2012)


    We want to create a virtualization within our database to reflect the makeup of a class in code ... what is better for this? A View or a...

  • RE: Table-based Functions vs. Views

    SQLKnowItAll (5/9/2012)


    A stored procedure returns the columns needed for the app, independent of the table structure. So, if you have to add a column to a class you already know...

  • RE: Table-based Functions vs. Views

    Allow me to rephrase my question to get off the particulars.

    We want to create a virtualization within our database to reflect the makeup of a class in code ... what...

  • RE: Table-based Functions vs. Views

    Lynn Pettis (5/9/2012)


    Why do this:

    Table --> View (or iTVF) --> stored procedure --> App

    When you can do this:

    Table --> stored procedure --> App

    You haven't justified the need for the...

  • RE: Table-based Functions vs. Views

    SQLKnowItAll (5/9/2012)


    I think the "real" problem here, that you are avoiding, is that the database schema keeps changing. If it was designed properly to begin with, you would only...

  • RE: Table-based Functions vs. Views

    Lynn Pettis (5/9/2012)


    Putts (5/9/2012)


    GilaMonster (5/9/2012)


    Putts (5/9/2012)


    Any change to the table then forces you to refresh all your SPs.

    Not at all. The only time that a procedure will need...

  • RE: Table-based Functions vs. Views

    You are just making statements now with no backing.

    What is the point of a table-valued UDF if not to return a resultset? Is that not the same purpose...

  • RE: Table-based Functions vs. Views

    GilaMonster (5/9/2012)


    Putts (5/9/2012)


    Any change to the table then forces you to refresh all your SPs.

    Not at all. The only time that a procedure will need refreshing if the...

  • RE: Table-based Functions vs. Views

    SQLKnowItAll (5/9/2012)


    No matter if you reference all the fields explicitly from ViewX in your SP or just simply do a SELECT * FROM ViewX, you will be forced to refresh...

Viewing 15 posts - 1 through 15 (of 70 total)