Hello Mr. Pataki!
you don't find what you want, add.This is to break up the pop-up list of categories. Once this area is broken up then every damn thing becomes easier. Every handling of the users, searches also within categories, everything. To be able to work on 200 - 300 Links is no joke. Mr. Pataki! Try and start with your new project with 4,00,000 and I challenge you, if you have four thousand categories, or more (Kind of every 1,00,00 Links have 1000 categories) and if you are able to run it efficiently without multiple admin, then I shall send a bottle of Chanpagne, an expensive one from Berlin to you as a present. Efficiency related to publishing, handling, ease to work by the users and the admin, etc. Let Alex be the Judge!!! 
Accept it, my dear. It should be however without any extra revision, modification, change in the codes, etc. Use neat script of the distribution.
Hello Alex!
I prefer this discussion here and not in other thread because if there is a message then I get an email and that notification is important to me not only now but also at a later date as this acute problem for me is important to solve.
Yes, Alex, I also agree. This would not help at all in any area of the function. Theoritically in MySQL one can also have everything in just one table. Evary thing gets dumped into one. But one needs to divide to be able to handle it better, regarding toe use, exports and imports, etc. Also the performance is considered.
This can also easiliy be incorporated in the main Links Table anyway. Moreover, a lonely LinksCategories table on its own for the export and the imports does not make sense. Once if there are some problems in indexing of the categories of auto_increment etc, the whole database may have problems. So the value assigned to a links MUST get into the same place and the moment it is broken up, chance of problems are automatically programmed for it to be born.
This would not be a nightmare to revise the program it, nor it would be a nightmare to implement. I have practically MEDITATED on it for now more than two months after I bought it from you. I also know what I am talking about. Its not just trying to solve the pop-ups. Had it been only the pup-ups I would then take several other apporach, for e.g. rather than spending my time in lecturing here, I would simply produce mass of add.cgi`s into different names and include all the pop-ups in there so that it does not have to get into the db_cat_gen_list at all. The time I spend here writing all this, which so much I have never ever done, is much more than solving it through cgi, that will insert directly into the database the correct value instead of using the table of categories.
But what then happens to the admin. What happens to the build routine and the performance, etc.
My suggestion here is to develop a table selector routine. This means that if a data is divided then it searches for the routine that searches which table to get it from. The name of the table is then a variable which is defined before.
This is the only first-class solution. There is a clear advantage in all areas as follows :
1 - Admin and the user pop-ups becomes automatically tiny and there is no byte etra download more than necessary. For every link only the category list is downloaded that where it belongs to the theme of the category, i.e. A link belongs to theme 1 & theme 2 then only sub-categories of theme 1 & 2 are downloaded.
2 - The mod of Alternate categories does not simply remain in the background but is brought in the foreground. One accepts at the start that alternate categories is not just a simply an extra option but a system how a project is going to be build. For e.g. Every link is to be inserted into two categories. So one designs the admin + add cgi accordingly.
3 - There may be a reduction in the build time upto 10-30%, I guess, however Alex may strongly disagree (And will I am sure). When there are hundreds of thousands of categories that the tiny little nph-build.cgi has to control with the help of MySQL then offering to this baby less data of each category list will give some speed to the build routine.
4 - One has then used a full power and the features of MySQL and not sticking with the limitations of Links v2.0 categories.db listings. So the buyers of Links SQL having an already running a setup database in ASCII format will simply have to undergo minor modifications of the categories listings + Links.db to be able to use the full power of MySQL build + search routines, especially when the lists are big.
5 - Links SQL then becomes an independently designed program that accepts all the Links v2.0 users but also having a design that it has been independently designed that does not have inherrent design limitation which has resulted at the moment. As a design by itself, it has then a greater value.
6 - I have suggested a table selector routine. This needs to be incorporated in the dBSQL.pm! So once done there may be many more ideas by experts to develop further mods on this table selector routine, which the name is a variable. This gives a wonderful possibility from the begining to have a platform from future development.
7 - This idea have comeup from a concrete problem. However this table selector routine can lead to further development and use. Lets say an alternative indexing method could be based on this table selector routine.
8 - Keywords searches could be oriented on this table selector routine. This means if I have all many tables for searches of keywords, then it is smart enough to select from a variable table and if it finds one it goes there and if not then goes to the general as a default. for e.g. keyword search if there are all the data stored on computers, a specific table for it, then the searches goes much faster in that table! Instead of loading the whole table having one millions of rows for the searches table if that itself is categorized before hand then it simply reduces to loading and use of memory + all the benefits. This keyword is captured from the user input and passed on or taken up as a variable for the table selector routine.
9 - I would go further and think about even dividing Links table by itself. If one can divide the table into five for e.g., then while building nph-build.cgi goes through the table selector and builds Links with the help of a table selector routine, from one table after anathor. When one has huge ammount of data stored in the table one has to think of all this. In just one table of Links it is loaded in the memory. The whole table. What if the server has 128 MB memory and my database is 250 MB where Links table itself has 150MB!!! When talking large directories this is size of a database is not said as a joke but a real life situation.
So therefore one is talking and questioning the very fundamentals of a concept. One triggers on the basic design concept. A change in the approach. The concept is to develop a general routine that is able to fragment database tables into many and be able to select it as an where required. It is only the fundamental revision in the very basic idea that can help Links SQL to run speedy and effective and fly in the SQL database and not a cosmetic solution of Java scripts and other things. They are nice and good solutions but only bringing a help to that perticular area. I am looking for a larger benefit out of a small change. This idea of a table selector routine is deadly to me. Because it gives an interesting power to Links SQL!!!
My question, Alex. Is this table selector routine so difficult to develop? It is such ideas that can really help Links SQL 1.02 take forward to Links SQL v2.0! I really want to see Links SQL v2.0 be one of the deadliest ones and killing one on the internet. By such a strong development environment and a backing of the programmer itself for the development, Links SQL is and would be the only one that can stand the market.
------------------
rajani
Quote:
I don't understand why you need to break up the category tables...... Just SELECT the category items you want from the table and if you don't find what you want, add.
Accept it, my dear. It should be however without any extra revision, modification, change in the codes, etc. Use neat script of the distribution. Hello Alex!
I prefer this discussion here and not in other thread because if there is a message then I get an email and that notification is important to me not only now but also at a later date as this acute problem for me is important to solve.
Quote:
Quote:
The Links table would not have any mention of the category, and the relations would all be stored in LinksCategories table as in:....This can also easiliy be incorporated in the main Links Table anyway. Moreover, a lonely LinksCategories table on its own for the export and the imports does not make sense. Once if there are some problems in indexing of the categories of auto_increment etc, the whole database may have problems. So the value assigned to a links MUST get into the same place and the moment it is broken up, chance of problems are automatically programmed for it to be born.
Quote:
To be honest, this would be a nightmare to implement. To break it up into ranges isn't worthwhile. The only hurdle you are trying to solve is the long select lists, which I think 1 and 2 would help solve, I wouldn't recommend breaking up the tables.But what then happens to the admin. What happens to the build routine and the performance, etc.
My suggestion here is to develop a table selector routine. This means that if a data is divided then it searches for the routine that searches which table to get it from. The name of the table is then a variable which is defined before.
This is the only first-class solution. There is a clear advantage in all areas as follows :
1 - Admin and the user pop-ups becomes automatically tiny and there is no byte etra download more than necessary. For every link only the category list is downloaded that where it belongs to the theme of the category, i.e. A link belongs to theme 1 & theme 2 then only sub-categories of theme 1 & 2 are downloaded.
2 - The mod of Alternate categories does not simply remain in the background but is brought in the foreground. One accepts at the start that alternate categories is not just a simply an extra option but a system how a project is going to be build. For e.g. Every link is to be inserted into two categories. So one designs the admin + add cgi accordingly.
3 - There may be a reduction in the build time upto 10-30%, I guess, however Alex may strongly disagree (And will I am sure). When there are hundreds of thousands of categories that the tiny little nph-build.cgi has to control with the help of MySQL then offering to this baby less data of each category list will give some speed to the build routine.
4 - One has then used a full power and the features of MySQL and not sticking with the limitations of Links v2.0 categories.db listings. So the buyers of Links SQL having an already running a setup database in ASCII format will simply have to undergo minor modifications of the categories listings + Links.db to be able to use the full power of MySQL build + search routines, especially when the lists are big.
5 - Links SQL then becomes an independently designed program that accepts all the Links v2.0 users but also having a design that it has been independently designed that does not have inherrent design limitation which has resulted at the moment. As a design by itself, it has then a greater value.
6 - I have suggested a table selector routine. This needs to be incorporated in the dBSQL.pm! So once done there may be many more ideas by experts to develop further mods on this table selector routine, which the name is a variable. This gives a wonderful possibility from the begining to have a platform from future development.
7 - This idea have comeup from a concrete problem. However this table selector routine can lead to further development and use. Lets say an alternative indexing method could be based on this table selector routine.
8 - Keywords searches could be oriented on this table selector routine. This means if I have all many tables for searches of keywords, then it is smart enough to select from a variable table and if it finds one it goes there and if not then goes to the general as a default. for e.g. keyword search if there are all the data stored on computers, a specific table for it, then the searches goes much faster in that table! Instead of loading the whole table having one millions of rows for the searches table if that itself is categorized before hand then it simply reduces to loading and use of memory + all the benefits. This keyword is captured from the user input and passed on or taken up as a variable for the table selector routine.
9 - I would go further and think about even dividing Links table by itself. If one can divide the table into five for e.g., then while building nph-build.cgi goes through the table selector and builds Links with the help of a table selector routine, from one table after anathor. When one has huge ammount of data stored in the table one has to think of all this. In just one table of Links it is loaded in the memory. The whole table. What if the server has 128 MB memory and my database is 250 MB where Links table itself has 150MB!!! When talking large directories this is size of a database is not said as a joke but a real life situation.
So therefore one is talking and questioning the very fundamentals of a concept. One triggers on the basic design concept. A change in the approach. The concept is to develop a general routine that is able to fragment database tables into many and be able to select it as an where required. It is only the fundamental revision in the very basic idea that can help Links SQL to run speedy and effective and fly in the SQL database and not a cosmetic solution of Java scripts and other things. They are nice and good solutions but only bringing a help to that perticular area. I am looking for a larger benefit out of a small change. This idea of a table selector routine is deadly to me. Because it gives an interesting power to Links SQL!!!
My question, Alex. Is this table selector routine so difficult to develop? It is such ideas that can really help Links SQL 1.02 take forward to Links SQL v2.0! I really want to see Links SQL v2.0 be one of the deadliest ones and killing one on the internet. By such a strong development environment and a backing of the programmer itself for the development, Links SQL is and would be the only one that can stand the market.
------------------
rajani
