Hello everyone!

Please pass a word or two what you think of my note that I posted yesterday in other part of the forum.


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

Actually, the flat file database is (in my opinion) better than what you are proposing. There is a competing link program that uses seperate files for each link and the searches are terribly slow. The regular version of Links is not designed to handle databases above about 500 links. Once you start going above about 500 links, SQL is the way you should go.

As for a 70 MB links.db file... I haven't heard that one yet, but if someone has a links.db that is that large, I would have to say that they probably need a higher end databasing solution to run their site.

Trekker,

Where did you get the idea that Links is not designed for more than 500 resources? I have over 1300 in my database and have yet to experience any problem with it. I am running both Links 1.1 and Links 2.0 (different databases though).

By the way, I agree with you that the flat file database concept used by Links should not be changed, although, having different databases by category (main only, not subcategories) might not be a bad idea to consider.

------------------
Bob Connors
bobsie@orphanage.com
www.orphanage.com/goodstuff/
goodstufflists.home.ml.org/

Hello Trekker!

Links Beta
Topic: Links with a LARGE database
elvii posted February 08, 1999 05:32 PM PST

Any suggestions on ways to get this working? As to database size, I'm using a 7MB categories.db and a 72MB links.db. Can Links handle this?

Trekker posted February 08, 1999 06:11 PM PST

Well... if you don't need the search function, you could set up Links locally on your own personal computer to do your builds. You could simply download the changed files whenever you add or remove links. Then you can execute the command perl nph-build.cgi and build your entire site. Then you would simply need to upload the pages that had been changed.
--------------------

This is what you answered to the question earlier. It was because of this I began to think on this problem.

I myself am evaluating different possibilities. I currently have submissions about 150 email requests per day. In this my link database could easily grow FAT quiclky. Thats the reason why I put this question.

I evaluated that 150 links in the links.db demo database brings 25KB and that too without description. With descriptions it may be 35 KB.

This would then create in my case daily 35KB production on links.db So ofcourse in 200 days I will have 70MB!!! In half a years time at the rate of 150 link requests.

Thats the problem. What I am interested to know is How fat is the database links.db created in relation to links? Would be nice to exchange this information.

Hello Mr. Connors!

With 1300 I beleive you may be having links.db size of about 250KB!!!

You mentioned of dividing the link.db by Categories. This my be true for your database. Probably not for many others. However, I beleive this is a wonderful suggestion.

What I had proposed is a vertical division in the fields in to different databases. What you proposed is a field division :Category/AltCat: within links.db

If I want to search for a keyword it then has to go through will the categories, anyway. This I do not know if it helps in search effectiveness.

If there is a vertical division of fields, like in Access : Tables : then searches could be performed within these fields. In case of links.db these fields are within a data. I suggested seperate data for each field. I therefore beleive this is a way of retaining all the function of links however increasing its search effectiveness.

Surfer could choose the search fields and then also could combine for e.g. Keywords only or Keywords & Description.

I didnot propose a seperate file for each link. Also a vertical division of fields within links.db in to different data will also result in to a Flat file. Correct me if I am wrong.

For e.g. If I import links.db in Access. There are for e.g. 1,00,000 links. At the rate of 200 submissions per day (Average) then the links.db IN ONE YEAR will grow in to 15 - 20 MB.

With this background the effectiveness of submission/Searches would considerably go down. If this database is imported in to Access the file will be about 120-170MB in mdb format. In both cases working on a shared server data exchanges (Remote><Local) is not practical anymore.

The only and the best solution I find is a division of links.db vertical fields. If the same database of links-db is imported in Access creating necessary tables and then EACH table is exported in to a seperate file, the result of searches within this file will be many times more effevtive. All could be linked with the unique ID number as in Access.

What do u´ll think of this?

Nice for your feedback.

Thanks.



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

Bob,

What I was trying to say kindof came out the wrong way. I meant that once Links tops about 500 links that you would want to move to an SQL database for performance reasons. I imagine that if you're not using SQL, your searches are probably pretty slow unless you're hosted on a dedicated server or a powerful system that doesn't have much overhead.

Hello Mr. Trekker !

Due to my lack of english, I try to understand.

You mean SQL types of databases and not links 2.0?

Then in my case, It would be so that I would need about a month to configure links 2.0 and then after it is launched three days later I will have to change!!!

Any suggestion to what kind of SQL databases solutions? Would appreciate a lot.

Thanks


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

Hi Trekker,

I think 500 is a little low. You can usually get up to 1500 on most ISP's (a lot of people can get up to 5,000 with reasonable performance). If it's slow with only 500 links I'd suggest moving ISP's as the system is pretty poor.

Cheers,

Alex

Hello Alex!

Reading some other threads, I am confused.

Does there exist an SQL links v2.0 version as well?

Thanks

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

My links.db holds 1200 links with a lot of additional fields (27!). The Size of my Links.db is 750KB, check out the search an tell me if you think it is slow.

http://Download-Tip.de/cgi-bin/search.cgi

Links need less than 2 minutes to create all pages include the detailed pages and a little bit nice stuff for my eyes only ;-)

------------------
Regards

Lothar Jung
http://Download-TIP.de

Hello Eljot!

I have ofcourse visited your website long before you answered this question. For your kind of a database thats no problem.

I receive about 150 link submissions per day. Tell me what would happen in one year with my link.db !

This rate per day is now. What when it increases?

See at www.AtoZ.com

I am in Berlin.
You have made an EXCELLENT website. Very Very impressive. The only thing of the Uebersicht is that it is designed for "Good eyes". Thats what my friend critisied looking at my webpages and the index on the left. He said why the hell I think every one in the world have good eyes. I noticed this then I was showing my webpages to a woman, 54 yrs., and see had to go close to the Bildschirm to check which index link she should click!!! I am sure she would´nt download a byte from your website links. Just a joke.

Thanks


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

Links has worked for me at 4,000 with okay speed, although abit slow, 2,000 links is quite fast on my host.

Hello TedW!

Thanks for your reply.

I made a request to all to answer in

Statistics.

http://216.169.107.32/scripts/forum/resources/Forum11/HTML/000117.html

It would be nice if you could also have a look therre and tell us all what you think about it.

------------------
rajani