Results 1 to 8 of 8

Thread: database and c#

  1. #1
    Join Date
    Dec 2007
    Posts
    1

    Unanswered: database and c#

    Hi,

    I am new on this but I am trying to do the following:

    I have a movie player that I can use to record some coordinates from some selected points (mouse click) for each frame.

    I want to store this points (they are different for each movie) so every time I open a movie I need to select points. Till know this is done but I want to put this data in a database.


    For this I need to create a database at run time something like this:

    Frame Number (column1)
    Time (column2)
    Point1 (column3)
    Point2 (column4)
    Point3 (column4)
    and so one.

    I need a primary key, but I want the Frame Number in column 1 to do this.

    Every time I open a movie I want to remove the database created early and create a new one with different number and name of points.

    I am newbie on databases so I hope that some one can help me on this.

    thanks
    Redcat22

  2. #2
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    So are you doing this in C# or Microsoft Access??
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  3. #3
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Hi redat22 - welcome to the forum

    First of all - are you settled on Access as a backend and C# as your front end?

    Secondly - don't dynamically create and destroy databases and tables - this is typically a bad practice and counter productive. It looks like you will be only storing a few bytes so just keep the data. In fact, if this is literally all you will ever store you barely even really need a database - a spreadsheet would be ample.

    Thirdly - that table design is typically a no-no (and is the sort of thing that requires dynamic table creation & deletion). It does not conform to first normal form and will usually lead to problems (one of which is the dynamic creation and deletion of objects).
    Check out this link for an excellent overview of relational design and normalisation:
    http://www.tonymarston.net/php-mysql...se-design.html

    If you design a permanent, normalised database you don't need to stress about creating dynamic DDL, and then creating dynamic DML to interact with it. You just need a few, fixed DML statements to insert, amend, delete and select data and you are good to go.

    HTH

  4. #4
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    You don't want to delete each record - you want to timestamp each and only select the top one!

    Also, this:
    Quote Originally Posted by redcat22
    Point1 (column3)
    Point2 (column4)
    Point3 (column4)
    and so one.
    Is a horrible design...

    What happens when you want a 4th point, and a fifth, and so on

    Have a read up on normalisation and post your revised design back here
    George
    Home | Blog

  5. #5
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Poots, did you seriously just suggest using a spreadsheet over a database for storing data?!
    George
    Home | Blog

  6. #6
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by georgev
    Poots, did you seriously just suggest using a spreadsheet over a database for storing data?!
    I'm not sure what came over me - I need a shower

    Seriously though - if sufficiently trivial I wouldn't use a database. Admittedly we don't know this based on the OPs information so far, but I store (for example) my personal "To do" lists etc in spreadsheets. Single table -> spreadsheet most of the time IME

  7. #7
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Single table -> spreadsheet most of the time
    Agreed there.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  8. #8
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    if theres not 'that' much data or its pretty simple (read fixed size and compact) then don't rule out flat files, or even loading into memory as an array (possibly both if the data is needed in between sessions).

    if its fixed format then reading a file at a specific offset would work.. mind you Im not certain that Access can read blocks from file at offsets.. so long since I had to resort to such tricks. I shudder to even remember the dodgy file handling tricks that used to be de-rigeur all those years ago.

    just because Access has a relational db storage mechanism, it doesn't mean that the answer is always 'use a relational table'. In my books if you only have one or two tables, then unless you have a requirement for some complex data handling or filtering then a relational db is overkill.

    if the data handling is largely linear then arrays, flat files are perfectly acceptable, but that quickly falls away if you need to analyse stuff.. eg find all values in range (a...b), find mean, compare film a to film b, etc.... now that changes everything a relational db would be ideal.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •