Home/ Questions/Q 1000831
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T07:34:29+00:00

If one of relational databases paradigms is to be tuple oriented we have the

  • 0

If one of relational databases paradigms is to be tuple oriented we have the biggest limitation here.

If one could design column oriented db, that would improve performance a lot.
Vector operations would perform out of the box, indexing, hashing for simple symbol columns lookups, linked lists behind the scenes as engine.

Memory mapping: dumps in huge chunks in microseconds as well as loading those disk images.
And still have use well understood and standard language (SQL) that multiple vendors support.
Imagine how many tools could be designed for interfacing that thing, because of its simplicity.
Wouldn’t it be more robust (and KISS at the same time)?

UPDATE
Thanks to all contributors.
Question has been unjustly closed, though i’ve found your all answers very informative.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Are all modern RDBMS row oriented?

    No. They’re designed for specific tasks, say OLTP vs OLAP. Even the popular ones like MySQL have column-store engines (ex: Infobright). And there are DBMS’s that are built as a column-oriented DB from the ground up as well.

    Here’s a potentially interesting read for you: C-Store: A Column-oriented DBMS (PDF format)

    LucidDB is a popular column-oriented database for data warehousing and BI:

    LucidDB is the first and only
    open-source RDBMS purpose-built
    entirely for data warehousing and
    business intelligence. It is based on
    architectural cornerstones such as column-store, bitmap indexing, hash
    join/aggregation, and page-level
    multiversioning.     Most database
    systems (both proprietary and
    open-source) start life with a focus
    on transaction processing
    capabilities, then get analytical
    capabilities bolted on as an
    afterthought (if at all). By contrast,
    every component of LucidDB was
    designed with the requirements of
    flexible, high-performance data
    integration and sophisticated query
    processing in mind.     Moreover,
    comprehensiveness within the focused
    scope of its architecture means
    simplicity for the user: no DBA
    required.

    See its list of features for those that overlap with your interests here: LucidDB Features

    And still have use well understood and
    standard language (SQL) that multiple
    vendors support.

    You can use SQL with LucidDB.

    • 0