[V4MD] API string search, dir example request //RULES OF API WAY
Olivier
vidal_olivier at yahoo.fr
Fri Apr 1 11:38:43 CST 2005
Hi Paolo,
I do not know V4MD but I DEEPLY advise you to look in valentina's list
archives at e-mails having the following subject:
SQL and API methods + benchs (24 january)
API methods on binary link // Philosophy (!!) (25 january)
API methods + binary link + M:M tables (31 january)
BinaryLink vs ObectPtr (24 january)
E-mails while dealing as V4RB but who can be VERY useful for you to
understand the API.
Here are SOME extracts:
-------------------------------
API methods on binary link // Philosophy (!!) (mail of 25 january)
It seems to me, that your task better solve in the SQL. You need do
joins,
you need sort joins, you need display results of joins to user in the
table.
Navigational model, as I have told, oriented on other tasks. It is good
for
tasks when algorithm require navigation from record to record, to do
some
calculations...
Or may be you need change your mind a little, and way how work your app.
***********************************************
** Now I want to make VERY IMPORTANT points: **
***********************************************
* the main idea of relational model is that you split data into
different
tables, then you combine them back using JOINs.
* how looks join usually? One record of parent table is MANY times
joined
with records from child table.
T1.f1 T1.f2 T2.aaa1 T2.aaa2
T1.f1 T1.f2 T2.bbb1 T2.bbb2
T1.f1 T1.f2 T2.ccc1 T2.ccc2
T1.f1 T1.f2 T2.ddd1 T2.ddd2
* What you get as join table?
apples + oranges
Look on your table:
Paris + street
But may be it is better to show to user
list of cities:
AND the parent list of streets?
In this case PARIS will present only once on monitor.
And streets will be show in other datagrid.
This solution CAN BE much better because
1) you do not spend time to build JOIN table.
2) you do not eat any bytes for JOIN.
3) on monitor you eat less space for duplicates of PARIS.
4) it will work much faster, because you
- display at first cities.
- IF user click some city then you FIND only linked streets.
You see?
You do much less of work!!!!
---------------------------------------------
SQL and API methods + benchs // Philosophy of API way. More (mail of 25
january)
In my prev letter I have show the main difference of SQL and
Navigational
worlds.
SQL *MUST* do joins.
JOIN in fact is very heavy operation!
If you will correctly make GUI of app. Then Navigational way can do much
less of work to get the same data to display for user.
btw, have you see 4D ?
4D and FM have so-called Related-View.
Remember?
It is easy to see that this is because both 4D and FM,
do not use SQL way.
** Your main problem is that you really try find *equivalent* of SQL
In the API way. But this is bad idea.
API way this is OTHER world.
It require different GUI, different coding, different thinking.
-------------------------------------
BinaryLink vs ObectPtr (mail of 24 january)
> Hi Ruslan,
>
> There is a big section in your notes about Abstraction Links, which
> mentions
> Foreign Keys, ObjPtr Fields and Binary Links. Are there any other
> kinds of
> links or keys? Of course, we support a primary key, right?
Yes we support PRIMARY KEY. This is Relational model.
PK + FOREIGN KEY = this is Relational model.
This is the only what have all other RDBMS.
Valentina 1.x also did have ObjectPtr,
Although 1.x did not support PK+FK completely.
Valentina 2.0 support 3 kinds of links.
FK
ObjectPtr
BinaryLink.
ObjectPtr -- this is analog of DIRECT POINTER from Navigational model,
although it differ.
FK -- this is pointer by value.
BianryLink -- this is totally new thing. Nobody have it.
it is best then both above
-----------------------------------------------------------------------
On 12/30/04 11:55 PM, "Lynn Fredricks" <lfredricks at proactive-intl.com>
wrote:
> Hi Ruslan,
>
> In your doc, you mention that ObjectPtr fields are up to 4 x faster
> than
> foreign keys. But what are the advantages of using a Binary Link (is
> there
> anything other than M:M)?
* M : M this is already HUGE advantage!
* I am going write many text on this in docs, because this thing is not
describe in books.
* another main advantage is DESIGN of db structure.
Look, with FK and ObjectPtr to link 2 tables you must insert FK field
into
one of them, which play role of pointer to the parent record.
The you have T1 which point T2.
T1 have 3 own fields that describe it info (its real world object).
Now you need add 1 pointer field to establish link.
If around T1 you have 5 tables which must be linked,
then you will have 3 + 5 fields in T1.
Look, 3 fields which keep ESSENTIAL DATA of this table,
And 5 fields which keep LINK information.
LINK information is NOT a property of T1 object,
But Relational model push you insert this info into T1.
This means that IF you change db structure, you will MUST change
structure
of already existed tables to add links.
It is obvious that this is bad.
All programming languages try isolate one part of code from other.
BinaryLink (as well as Link abstraction) DO THIS for DBMS world.
You will have in T1 3 fields. Always.
(of course if you use BinaryLinks only :-)
If you add/remove linked tables, then you just add T3 and new
BinaryLink.
T1 is not touched.
-----------------------------------------------------------------------
>> FK
>> ObjectPtr
>> BinaryLink.
>>
>> ObjectPtr -- this is analog of DIRECT POINTER from Navigational model,
>> although it differ.
>>
>> FK -- this is pointer by value.
>>
>> BianryLink -- this is totally new thing. Nobody have it.
>> it is best then both above
>
> Best for what? Speed? That is what I need to understand -- in
> marketing 2.0,
> I need to convey why this new type is better.
SPEED also.
And BinaryLink will use about 2 times less disk space then trick with
third table to establish M : M link as do RDBMS world.
-----------------------------------------------------------------------
>> The you have T1 which point T2.
>> T1 have 3 own fields that describe it info (its real world object).
>>
>> Now you need add 1 pointer field to establish link.
>> If around T1 you have 5 tables which must be linked, then you
>> will have 3 + 5 fields in T1.
>>
>> Look, 3 fields which keep ESSENTIAL DATA of this table, And 5
>> fields which keep LINK information.
>
> There is where Im getting confused.
>
> There are three fields of real world data in T1.
>
> There are five tables which must be linked to T1, so therefore, T1 has
> 3
> fields (of real data) + 5 link fields (to connect to each of the five
> other
> tables) = 8 fields.
Correct. And in RDBMS, these 5 fields are FOREIGN KEY fields.
Also note, may happens that 5 tables POINT TO T1,
In this case each of them get this additional FK field,
but T1 have 3 fields. In any case, db have 5 more fields in total.
>> LINK information is NOT a property of T1 object, But
>> Relational model push you insert this info into T1.
>
> With Binary Links, where is the information stored to make the link,
> if it
> is not in T1?
It is stored in the NEW SPECIAL structure -- Binary Link.
Internally this is NOT a table. It is quite other format (similar to
indexes).
--------------------------------------
NOTE: in RDBS, developer also can have
T1 with 3 fields, and T2..T6 tables around it.
to get better design developer can make links as
additional tables with 2 fields each:
T12 -- link T1 and T2
T13 -- link T1 and T3
...
in case of M : M developer simply MUST to use
additional table.
NOTE2:
in pure Relational model exists ONLY tables.
even indexes not exists, so strictly speaking
all RDBMS as MS, mySQL are not pure Relational.
* So we do step forward and add one more abstraction LINK.
* and we have 3 kinds of links.
So as I have told, BinaryLink is not a T12 table.
This is special kind structure. It is smaller and faster.
And the main, it act as abstraction LINK.
>> This means that IF you change db structure, you will MUST
>> change structure of already existed tables to add links.
>>
>> It is obvious that this is bad.
>> All programming languages try isolate one part of code from other.
>>
>>
>> BinaryLink (as well as Link abstraction) DO THIS for DBMS world.
>> You will have in T1 3 fields. Always.
>> (of course if you use BinaryLinks only :-)
>>
>> If you add/remove linked tables, then you just add T3 and new
>> BinaryLink. T1 is not touched.
>
> So is the Binary Link data stored in its own sort of table and contain
> all
> information related to the linked tables?
Yes. Close to true. Just it is not table.
You can think about Binary link as array of pairs
{ 3, 5 } rec 3 of T1 is linked to rec 5 of T2.
{ 3, 7 }
> And so if this is true, then no
> linking information needs to be stored in T1, right?
Right.
---------------
Olivier
More information about the Valentina
mailing list