Most of us knows the limitations of a Flat file databases. If the Links.db can be divided in different parts i.e. linksaf.db :- Links starting from the first URL A to F, linksgz.db :- Links starting from the first URL G to Z.

In this way the webmaster could divide the growing database into different parts as required.

However the basic function of the links 2.0 should not change!

Moreover if a script is written as a part of submission to sort URLs only websites and webpages. For e.g. if the webmaster wants to update website at a moment he can validate only those at that time. Something like this.

Also what if a seperation of the fields in Links.db are done from the begining and each field is linked only with a Handle no. at the begining of a line. This means that in the Search routine one can define if the search is limited to "Only Keywords, only in description, etc"

Has anyone has to say how to go about it?

------------------
deepy rajani

Wouldn't the computer then have to search each database for the keywords? Prob not saving much time?

I would like to seperate links information and contact information in different file.

Hello Mark!

As an Architect, (based in Germany, Europe) I am very much used to questioning the fundamentals of a concept. However, I think I should try not to bother the experts on this beautiful platform of forum discussion here, I beleive, but its hard to stop meditating on the fundamentals.

Talking about the concept. Links.db is a "FLAT" flie Database. When I downloaded the Links.db from the Demo area, I first thought this is a "FAT" File Database. (Hey Alex, Excuse me for my humour). However has a beautiful chance to grow in to a beautiful program.

Mark!

Hello.

To your question. Instead of creating this Fat File database, if "FRAGMENT" File database concept is developed, then

- Surfers can specify where they can look for the information. For e.g. Only in Keywords, OR Keywords and Description, OR only in Description, OR also only in the LINKS URL!!! (Similar to www.Whois.Net)

SO therefore one begins to setup fundamental direction from the begining.

My spontaneous reaction to see the LINKs.db was - Like landing in a city without a Map. A big thing is in front of you. I am in this city of Links.db --- I am lost ---

Thats what is beautiful about MySQL and other databases. An object within a database is not
lost. (Here lost is probably a wrong word, but excuse me for my English). Or better said "Could be easily Captured!!!"

Here in the Links.db Objects are to be captured only through a tremendous "Going throughs". What a pain! This is only a result of - How a program writes a Database fundamentally. It is therefore on this some basic change needs to be done and I can challenge that there cannot be a better program then this, on this level.

One Uni. Admin wrote here, OOOps my Links.db is "Seventy MB" I cannot upload this every time and work locally publishing pages. I am sure he would be paying Millions of thanks to Hon. Mr. Alex _______ if he had designed or better said programmed a DIETING routine with the Links.db not to create a FAT file database.

CONCEPT :
SQL could capture an object by tables and cells. Why not the Links program create files
seperate for each table.

In the above example of 70MB then this will be divided in to 3 + 4 + 45 + 9 + etc. The search and the submission will then trigger only on that particular file.

Recently I myself was developing "A concept of a search within a database". Due to lack of technical knowledge I stoped developing this patent.

Anyway, using links.db seems to be a solution for many millions in the world. What I do not understand is how much time Alex is taking to bring this updates. 1.1 >>> 2.0 It somehow does NOT match with the speed of the growth on interNET.

However, I like it and I "AM convinced" that it could be a beautiful program in the future.



------------------
deepy rajani



[This message has been edited by rajani (edited February 15, 1999).]