Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: Maximum columns in a table

  1. #11
    Hi Dilip,

    I guess it would depend on what your needs are.
    For example, SQL Server and Oracle are Relational Database Management systems.

    Lianja is an entire framework. From local or remote databases and tables, to JavaScript web pages, to mobile app development to robust desktop apps that easily combine VFP, Python, PHP, Javascript, TypeScript, C and C++.

    How many applications need 1000 columns in a single table? I can see some data analytics possibly designed that way.

    If you look on the Roadmap, at Lianja SQL Server 6.0 release (Codenamed JackalDB), there will be a Major upgrade to the Lianja SQL Server.
    It may very well be that in that release the columns limit may be larger.
    If this is something that is critical, you can submit an Enhancement Request and the Lianja team will definitely evaluate it.

    They may pass on it, but you can submit it.

    Herb

  2. #12
    Lianja MVP
    Join Date
    Feb 2012
    Location
    Berea, KY, USA
    Posts
    2,185
    Hi Dilip,

    If you want to compete in the market, you have to use best practices. And best practice is to make your database into Fourth Normal Form, at least. Assuming you have covered normalization in your studies, you will be aware of the tradeoffs between speed and clarity that play into the decision whether to go all the way to Fifth Normal Form.

    There is an economic side to using best practices: for the past 20 years the figure I have seen is that 60% of development costs are maintenance, not implementation. As I have told clients for that same amount of time, I will not help you hurt yourself economically by showing you how to use a poorly designed database. I am surprised no one at your company is looking at this issue from that perspective.

    The Lianja database is very standard in its capabilities except in the areas where it outshines every other database on the market. I am referring the its use of oData for "diff's," and the ability to inspect and modify this diff to meet particular USE CASE's; and its separation of concerns by having metadata follow the data, rather than having it reside in code.

    My offer to work with you, here on the forum, in seeing what clarity might be achieved by redesigning a large-column-count table, still stands. Perhaps seeing what would be gained would convince your fellow workers. Or perhaps I'll be convinced it makes sense for that table to be designed the way it is. We'll never know until we do it. All the rest is pointless speculation.

    But of course if those at your company insist on maintaining bad practices regardless of evidence, then you have no choice. I realize you might have no control over this. There are always times in life when we have to "grin and bear it."

    Hank
    Last edited by HankFay; 2016-11-17 at 10:28.

  3. #13
    Junior Member
    Join Date
    Feb 2012
    Posts
    23
    Thanks Herb
    that's true

  4. #14
    Junior Member
    Join Date
    Feb 2012
    Posts
    23
    Hi Hank,

    yes, I have no control to redesign the database. but i can insist to migrate

    Thanks,
    Dilip

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Journey into the Cloud
Join us