|
|
Posted by --CELKO-- on 10/30/05 00:49
You are sooooooo screwed up I have to use this in a book! I am looking
for anything you did right and I cannot find it.
>> I currently have a selections table in the front end file [sic] which the users use to make selections of records [sic] . The table has two fields [sic] -- primary key (which matches primary key of main [sic] SQL Server table), and a Boolean [sic] field [sic] . The table is linked to the main table in a heterogeneous inner join[sic] . <<
Let's get back to the basics of an RDBMS. Rows are not records; fields
are not columns; tables are not files. These are FUNDAMENTALLY
DIFFERENT CONCEPTS. SQL does not have Boolean data types -- they woudl
screw up the 3VL that is the foundations of SQL's model.
>> I'm looking to move the table to the back end, while still giving each machine a unique set of selections. <<
Then these will not be the same table, will they? Duh!
>> Using one large table with machine name as part of the primary key actually slows things down. <<
Machine name?? Have you ever read anything on data modeling? Logical
versus Physical?? The basics!! The basics!!
>> So I'm considering using a series of tables, where each machine has its own table in the back end for selections. <<
Sure, split the LOGICAL design over the PHYSICAL implementation. To
hell with the foundations of RDBMS, Data Modeling , etc. You are doing
1950's tape system in SQL.
>> The machine name would be incorporated in the particular selections table name, and the front end link would be modified on the fly when the database is opened to point to that machine's back end selections table. <<
You have just implemented a design we found to be a nightmare in the
1950's with magnetic tape file names. It is one of the reasons we went
to disk systems and then to navigation database and then to RDBMs
systems.
>> This would require having about 50-100 individual selections tables in the back end database. Also, if a machine doesn't have a table when the database is opened on that machine, then that table would be created on the fly, populated, and pointed to via the ODBC link. <<
Back to basics. A table models a set of one kind of entity or a
relationship. Then schema models the reality of the data model in
those terms. Creating them on the fly is the logical equivalent of
having an elephant drp out of the sky.
>> Anyone see any problems with this approach, specifically creating the table on the fly and then immediately using it, as well as having that many little tables running around? <<
Dr. Codd,. Chris Date, me, anyone in RDBMS?
Please get some help before you hurt people. Everything you are doing
is wrong
Navigation:
[Reply to this message]
|