General Thoughts....( ver 2.x vs. 3.x)

[Dan W]

Hi to Eugenio, ( & all the designers/developers) and to Debbie....


I seem to be wrestling with an issue that is holding me back from upgrading from the 2.x lineage to the 3.x versions. Mainly, the population of tables, with "data" from Foreign tables.

From the 2.x versions, Data/Values "choices" from foreign tables ( key/fields) would populate a given table. Now, it appears that the final data residing in a table is the numeric key (id) of the data.

In other words, if I presented choices of:
Red, Blue, Green, Black

for input into a final table, the final table would contain that choice (Red or Blue, etc.)

Now, In 3.x, my "final" table would hold the "numeric Key" of Red/Blue/Black etc.- In other words,


CHOICE_TABLE
---------------
ID | Value
---------------
1 | RED
2 | BLUE
3 | GREEN

====================

FINAL TABLE ( 2x )
------------------
RED
GREEN
GREEN

Vs.


FINAL TABLE (3x)
-----------------
1
3
3


... etc... etc...



SO, While I see that the main goal is: "DaDaBIK's target user is not the DB administrator but rather the final user."


This presents a problem for any future use of "a table filled with numeric choices".

This means that you cannot dump/search the table using "Other means: MySQL, or scripts", unless you use Subqueries..

Personally, I would rather have the "true/final" data in a table, then key_ids..


Maybe I'm missing something ( as I have many times over the years ) , but I thought I would write and comment -

Keep of the great work!

dan

 

[Debbie S]

Dan

Actually, with version 3.0 and up, the data from linked tables is presented how you choose the data to be presented.

With a linked table in 3.0/3.1 set up like this in the admin.php page using your example above):

Primary key field == ID
Primary key table == CHOICE_TABLE
Linked fields == Value
Order by == either field depending on how you want the drop-downs in single_select fields to be ordered.

Will result in the following displayed in the DaDaBIK view:

FINAL TABLE (3x)
-----------------
RED
GREEN
GREEN


Now, if you wish to export the data to CSV using the tool included with DaDaBIK 3.x, the VALUES are saved to the CSV not the numeric ID for the field.

To see how this works, you can download one of the sample databases I posted (see forum post >>> http://www.dadabik.org/forum/read.php?f=1&i=2740&t=2740) and test out the export feature.

While I understand your preference for having actual values embedded in the database rather than IDs, linking tables via primary key ID proves to make the database more flexible.

With this format, a user can change the value of record 2 in the choices table and that change is reflected in all instances where that id was referenced. Using values embedded, a changed value can result in data not being displayed at all or even breaking parts of the program.

Hope this helps.
Debbie
(Latest version of DaDaBIK when this message was posted: 3.1 Beta)