No announcement yet.

Belated fuzzy along with Database general specs feedback request

  • Filter
  • Time
  • Show
Clear All
new posts

  • Belated fuzzy along with Database general specs feedback request

    A little late, but I was on holidays...
    Just another big thank you for all the help from every one over the past year.
    And a thank you to PowerBASIC. PB6 has been an essential tool for fun in university and has continually outperformed other classmates projects.

    Business is going alright with much to do and little time.

    And then for the real topic: The TCP relational database server I have been working on will be complete and ready for distribution some time late this year. This database will be freeware and open source for all PowerBASIC programmers. However is will be copyrighted to prevent resale as well as translation to another language... emphasis on the “for PowerBASIC programmers only”. We do intend to market and sell the database outside of the PowerBASIC community.

    This database should be an ideal solution for PB programmers working with small to medium sized database needs. If all goes well it should be ideal for large databases as well, however it is still to early in the game to tell for sure.

    The major limitation of the current database design will be that in an exchange for an extreme speed increase, it will hold a cache of the entire fixed-width-field section of the database in memory, thus limiting the working database size of the fixed-width-field section to that of your server’s physical RAM. However, there will be a method for archiving unused data. This will of course come with a method for specific access the archived data, but at a slower speed. Feedback?

    The database will allow for UDT fields (absolutely anything.) Fixed width data types for speed. Variable width data types for a slower lookup but which may contain such things as entire files of absolutely anything such as music and video! Then there will be field, record, and table pointers types that will enable the use of my favorite part, continually updated queries that may be simply read without compilation at any time. The database server already makes use of multithreading and individual record locking.

    It is still up in the air as to the possibility of multiple servers working on the same database in order to allow for a larger client connection base, this might have to wait for version two.

    Specific Question to all who are interested: Would providing SQL support be essential, or would a much more programmer friendly (streamlined) communication process be better? At this point I’m thinking both, but don’t want to waist time and code if not necessary.

    Any other feedback or suggestions? The more feedback and suggestions I get the more time I’ll put into it. If this is of no interest then I’m happy to keep it proprietary to our needs.

    Later on this year I’ll be looking for beta testers as well as those with general expertise that may be interested in optimizing key sections with an experienced hand in assembler.

    Colin Schmidt
    Praxis Enterprises (just a little consulting and design company with big visions)
    Chilliwack (1hour east of Vancouver), British Columbia, Canada
    (and yes it is raining here)

    [This message has been edited by Colin Schmidt (edited January 10, 2001).]

  • #2
    I would be very interested in your database. I provide business
    applications to a vertical market and am looking for a good
    database to use. I have been using multi-value databases for
    years and am sick of having to pass on the expense of these
    products to the client. I am willing to pay for a good database,
    but I don't want the customer to also have to purchase a license
    for it. It seems bizarre that the database should cost more than
    the application itself.

    In any case, I personally don't see the need for the database to
    support SQL (or ODBC) as long as there are methods built in that
    can be accessed via the program using the database.

    Regards... Ed



    • #3
      Thanks for the feedback.

      Just another note, we have now developed/designed a method for distributed data as well as client connection distribution. This should be including it in the first version making it a much more powerful and flexible solution.

      The plan so far is that the database will be accessed by a client program via wrapper functions in a DLL or you may also have these wrapper functions simply included in your code.

      Colin Schmidt & James Duffy, Praxis Enterprises, Canada

      [This message has been edited by Colin Schmidt (edited January 12, 2001).]


      • #4
        Sounds exactly like the way I want it to work. My programs run
        on multiple clients which access a database server. Whereas I
        prefer to be able to deliver stand-alone client programs, having
        the database access functions in a dll is fine... In fact, that
        is the way I currently do it for accessing mv databases or even
        binary files on the client.

        Looking forward to seeing what you have come up with.

        Regards... Ed



        • #5
          If you intend to sell it to the non-PB public as a database tool for use from their
          non-PB programming languages, then I would say SQL is an absolute must.
          From a business perspective, I would usually sacrifice performance if it
          meant I could find programmers who already are familiar with the language.

          Since we are (currently at least) only discussing a Windows server, I would
          also think that ODBC would be equally important. It doesnt matter how
          good your tool is, if I can't use it with my XYZ off the shelf software,
          then it is useless to me.


          John Kovacich

          John Kovacich
          Ivory Tower Software