Only if you don't care about performance.
You may have to break up tables or physically cluster tables together to
get the performance that you want based on the pattern of access and the
actual columns that will be requested together.
It is hard for a database system to know how many records you are going
to add when you declare the first node and what the pattern of access
will be when you store the first record.
Ron
On 14/11/2015 1:37 PM, Clay Ferguson wrote:
Sorry Ron,
You have it precisely backwards. In RDBMS modeling you focus on the
organization of the data and relationships of the data, and never break
stuff up to "help" the DB loading. For example, once you see the need for a
PERSONS table, you generally have just *one* PERSONS table even if you have
millions of people. In an RDBMS you never find yourself searching for
patterns in the data just so you can break stuff up to help provide a
crutch for the DB engine. DB indexes are all that are required to solve
scalability. NEVER breaking up data.
-Clay
On Sat, Nov 14, 2015 at 11:43 AM, Ron Wheeler <
[email protected]> wrote:
Even in an RDBMS application, the database designer has to be aware of the
physical structure used by the implementation if you want to have
reasonable performance with large numbers of records.
You have to do tuning and give some thought to the way you structure your
tables and indexes.
That may mean splitting tables in ways that have little to do with the
business logic in order to get the best performance in the most common or
critical cases.
That is why we have database administrators and courses at the university
level on data structures.
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
