LEADER - current version:
1.0.0.7 Beta

A screenshot of Leader 1.0.0.7 BETA:

Revision History
From 1.0.0.6 BETA to 1.0.0.7 BETA:
1. Added a Reset All Term Views to zero feature.
2. Added an independent interface button for the feature: Reset All Errors per each term to zero.
3. Better navigational menus.
4. Some css improvement for Mozilla. From 1.0.0.5 BETA to 1.0.0.6 BETA:
1. Serious overlooked bug fixed: null value when Updating a term could be generated if inserting empty Author or Source fields in the Examples set. This caused malformed queries when a search brought up such updated value. Fixed. From 1.0.0.4 BETA to 1.0.0.5 BETA:
1. Fixed a minor bug in the javascript for the Default drill and the Errors drill. Much better javascript checks introduced.
2. Default drill and Errors drill: better javascript field checks: autoremoves double (or plus) commas.
3. Clean Up button: added a checkbox option to remove all the errors dates and errors amounts from the database (useful to clean up errors recording that is by now obsolete: you do not make those errors anymore, so you do not want the term to be still registered as one upon which errors occurred)
4. Better errors.php file From 1.0.0.3 BETA to 1.0.0.4 BETA:
1.Added slides numbering in the Slideshow drill.
2. Added the Errors Drill
3: Default Search Term by term name is now set to 'starts with' rather than with 'exact match': such new default option, in fact, accounts for both cases, being less restrictive.
4. Default drill and Errors drill: better javascript to perform comparisons (it requires now a perfect match and not just a substring match, which latter was ok also with partial answers) From 1.0.0.2 BETA to 1.0.0.3 BETA:
1. Added the current database on request Back-Up utility (works only if you are on your local machine, on an online server this feature should be removed).
2. Default Drill: improvements in the javascripts for the Hints and in the interface.
3. Added the Slideshow Drill. From 1.0.0.1 BETA to 1.0.0.2 BETA:
1. Added the Search From Native (and not only foreign) language feature.
2. Default Drill: the javascript now ignores the possible double (or higher) whitespaces in the user provided answers.
3: Added in buildup.php a table named 'version': it is constituted of one id field which holds the current version as a varchar string.
4. Added the hint buttons to the default drill.
5. Fixed a bug in the default drill: one synonym went missing from each record of the right answers set. From 1.0.0.0 BETA to Version 1.0.0.1 BETA:
Fixed a bug: null sql field upon adding a new term was included in the literature table if an example was provided but no author or source for it. Such null sql field caused halting of a search process when trying to query the specific record where the null value was.

Leader is released Open Source under the copyright agreement as per the:
GNU General Public License

Leader is an acronym for: Language E-learning Auto Drilling Expanding Routines - and I will account for every single letter of it.

It is a package made up of:

• PHP original scripts and classes, meant to build and use the Leader SQL database.
• Sets of mySQL queries.
• Javascript original scripts and classes, and related original Dhtml interfaces.

The purpose of this package is educational, and it is to provide a browser-oriented environment where you can improve (by training on your own and via html interfaces) your knowledge of whatever language of your choice without the assistance of any teacher.
Of course, this is no real substitute for a teacher: but it is an instrument that allows you to exercise yourself with what you have learned, as far as it is possible, also in absence of a teacher, that is.

This is all achieved by building up a mySQL database via the Leader's PHP scripts and end user interfaces, and by providing you with all the additional scripts to populate, use, manage, update, and run such database.
The database is not populated with preset entries or records: you will be the one who populates - and who updates it - accordingly to your own current needs and preferences.

In fact, once put in place Leader, its database can be populated by yourself by inserting in the designed html form fields the terms (vocabularies) in any foreign language of your choice, defining for each term in the other designed html form fields all the data that can characterize this term - from its translation(s) in another language in your native language to its categories (gender, number, typology of the term etc.) to its synonyms to a true wealth of additional data (all optional!).

Like a belated version of the old Java programming saying popular among geeks time ago, and that went «Install Once, Run Everywhere», well with Leader you too now! Get one Leader package, and with just that one you can get as many databases as you want: you can decide to set up via the single Leader interface all the databases you want for all the native language versus foreign language pairs you may wish to set up: they can all coexist without interfering with each other in the least.

Subsequently, Leader makes it possible for you querying such database emulating a small search engine on your local machine.
Although I can not afford and I am not in the least comparing myself to Google Desktop Search, yet my approach should not surprise you at all: after all, it is exactly a concept similar to the Google Desktop Search: I find in fact myself developing tools that seem to follow a few market trends that Google seems to be following itself: this synchronicity is not intentional though, but for instance I was developing a set of FORM FIELDS AUTO COMPLETION DROP DOWN MENUS BY BINARY SEARCHES ON PARTIAL OR FULL MATCHES at a time when, apparently, Google too was working on that challenge via Google Suggests: «As you type, Google will offer suggestions» (of course at a much higher level, this should go without saying).

But most significantly Leader makes it possible for you to use specifically designed sets of html interfaces from where you can pick from a group of possible available types of exercises (called drills) and trigger them.
By the way these drills can increase in number over time, and you could even design your own if you know Php - which is where I can finally account for the part of the acronym that recites: "Expanding Routines": you can expand them, if you know Php.
This is why I called this project Open Source and not a copy and paste class or script.

These drills consist in this, in their default form: by typing in form fields the answers that the drill prompted you to fill in, you can significantly increase your familiarity and proficiency with the vocabulary of your chosen foreign languages drill: fill in, and then let Leader, your homegrown oracle, tell you where you did it right and where you made a mistake.
Should we stress the importance of having a fluid vocabulary when using a language?

Leader is not a substitute for a teacher: Leader cannot teach you the grammar, but it can help your teachers to get relieved of the less creative, and yet pivotal, aspect of teaching, namely dealing with the vocabulary teaching: Leader can make the process of memorizing and getting proficient in using the increasing vocabulary, a thrilling and a more and more satisfying and fun experience.

Leader is designed in its first drafts to run exclusively on your local machine.

Yet being a clearly and definitely browser oriented environment (no pain no gain, I guess; and no browser, no glory; and no browser, no Leader baby), it can be easily rearranged to implement regular websites either for public or for member reserved accesses, and this either on a globally predefined set of database vocabularies meant to be used by all, or as an online space where surfing members can build on the remote server their own custom language databases.
You are the Leader; you decide.
And should I stress I worked on it, alone, for many weeks, and that it is 100% freeware?

In fact Leader has been conceived, developed, and implemented in this original draft by one single programmer (me). A product that does this, namely allowing you to exercise with a vocabulary and moreover in a somewhat entertaining way, to date, simply did not exist.

In its first Beta release it weighted, once unzipped, over 300,000 Kb which is normally the size of a dignified software: for instance such was the weight that had the earlier versions of Irfan View, by far one of the most interesting graphical image viewer (and anyway, since ever, my favorite one), and which is till today (2005) entirely freeware (by the way, terrific job mr. Irfan Skiljan of the Vienna University of Technology!).

You'd be aware that normally for such complex applications whole teams get hired (and paid): thus Leader goes with a few caveats:

• It is possible that various imperfections, either in a few scripts or in the conception of a few solutions can be found.
  This does not mean you will encounter dramatic bugs that go overlooked for months: as far as their functionalities are concerned, the whole package is released bug free, which does not really mean you cannot find a bug, but that as far as I, the only developer, used and tested it, no script, no class, no function has been added if I was not first absolutely certain that it was going to provide a sufficiently sturdy behaviour for the given purposes I was testing.
  In this package no script has been included if first a significant amount of thinking has not been devoted to it.
  
  Yet you are aware that this product is for free, that there are not others, at least till beginning of 2005, like it, and that if I have included a few unsatisfactory technical solutions, this is because I really have no one to help me, not even a set of beta testers: I truly work like a cleric isolated to meditate into a cellar.
  
  Yet if you have observations, bugs and the alike, features you'd like to add, scripts you wrote for Leader itself, definitely feel free to email me!
• It is well possible that over time many additional features will be added. The package has been designed trying to keep in mind the necessity to change it trying to avoid loss of data. Therefore mySQL tables are atomic, meaning by that as restrained in their structures as it was possible while preserving their usability: no SQL table hosts more than two fields, which by the way I consider a way to force in the so called SQL normalization.
• You are aware that given the amplitude of the challenge, one single person working on it is entitled to overlook possible misconception: by misconception I mean things that do not hinder a feature, but that only perform a given task in a non optimal fashion.

Leader is currently using the following scripts featured here at Unitedscripters, which in a few occasions have been thoroughly thought over, pondered, and designed, or reshaped, exactly in order to work precisely with Leader, while retaining all their characteristics to be lent and fully used for any other general task in their kinship. This means that Leader is not so improvised a product:

1. PHP: PRINT FORM TAGS IN A COMPLEX HTML ENVIRONMENT DRAWING THEIR VALUES FROM SQL DATABASE QUERIES
2. JAVASCRIPT CLASS FOR SQL AND MYSQL PHP FORM SUBMISSION DYNAMIC INTERFACES WITH DYNAMIC ADDITIONS AND REMOVALS OF FORM FIELDS VIA DOM AND DHTML: THE FORM ADDER
3. PHP MYSQL DATABASE FULL MANAGEMENT CLASS SESSION INITIALIZER, MULTIPLE QUERIES, PROXY LOG IN, AUTHENTICATE AND REGISTER USERS WITH ONE SINGLE METHOD, CHECK PRIVILEGES
4. JAVASCRIPT DYNAMIC BAR HISTOGRAMS OF ONGOING PROCESSES
5. JAVASCRIPT MISCELLANEOUS FUNCTIONS #4
6. THE PHP SQL HELP DESK CLASS
7. PHP: IMPLEMENTATIONS #3 FROM JAVASCRIPTS: SCAN ARRAYS, IRREGULAR MATRIXES, SCAN AND UNFOLD DIRECTORIES, REPORT ALL FILES, FIND FILE/S

Leader is released in tis first draft to be run on your local machine.

This means that in order for it to work you need first to have:

• A PHP interpreter installed on your machine.
• A mySQL database engine installed on your machine.
• An Apache server that emulates an internet connection also if you're working offline.

Whatever your operative system is , you can easily install the whole of the above.
Mine is Windows XPP, which I hope won't surprise you: I do can conceive being open source and liking Microsoft too: I am a man who can walk and chew at the same time without finding any contradiction in it, and most significantly without seeing in Microsoft that all seeing incarnation of all those evils that, when we see them rallying so freely around so clearly symbolic a target, they are casted there cause they reside within ourselves infinitely more than they reside without: it is from there that they beam their shadows.

To have the mentioned Php/MySQL/Apache elements and engines, I strongly recommend to you to use the Apache2Triad Installer package that once downloaded (beware: over 70Mb, may take five minutes or two hours depending on your connection speed) can be installed via a simple double click of the executable.
The Apache2Triad Installer package is a well known and affirmed package that installs all the above (during installation, my advice is to accept always the default choices that it suggests).

If you use a different product, beware that Leader, when launched, will provide you with an interface where you have to fill in the proxy username and password: if you use the Apache2Triad Installer package those values are already set to the right default, otherwise you will have to know what they are for a different Php mySQL Apache package (because I cannot guess them via a vision, of course!).

If you have a Windows PC I recommend you to download it and install it (and if conversely you have a sophisticated Linux operative system, well then you are already enough of a geek to know in which thick online forests to find and hunt your daily games for your daily appetites): once there it should be under the files menu section (yet that package is meant for windows pc only, not for Macintosh):

Once installed that, you can download Leader in its zip format. Once unzipped, it will generate a folder named leader.

Assuming you have installed the Apache2Triad Installer package, just copy that folder as it is inside the directory of your local machine:
C:\apache2triad\htdocs
whereas the leading letter C might vary if that's not the letter used on your computer to signify the hard disk.

Then you can access Leader by simply opening a browser window and typing (and also, arguably, later bookmarking) in the location bar exactly this address:
http://localhost/leader/index.php
http://localhost/ is a default way to signify: emulate an online environment on my local machine, also if I am actually offline, considering it as if it were the... server of itself!

That will present to you an interface (if you scroll on, you'll find it. It is a mock up though and will not work or submit anything to the "local server"): as you see, it requires a proxy username and password. The defaults for Apache2Triad are provided as the defaults.

There is a choice you can make: choosing from the two drop down menus on that page the database name.
It can be done by selecting your native language name in one select menu and the foreign language name in the other, thus having a pair that Leader will use to build the database for that specific combination (unless it was already previously created, of course).

If you check the checkbox at the bottom of that file, Leader will not attempt to create any new database after the drop down menus selections, but it will merely try to locate a currently installed Leader version, and it will work with the first it finds (if none is found, it will build a new Leader database after the default or after the selected names in the drop down menus).

Upon submitting, Leader will (at least for now) verify whether in the leader folder:
\files\includes\version
is present a text file that will carry the current version number and the selected native language versus foreign language pair. If there is not any, the scripts will build the whole leader database from scratch (yet it will do this with this significant caution: it will be built only if all its tables do not exist already, so no fear that Leader may overwrite an existing set of database tables), after that given pair names.
If the file is found but the version mismatches, Leader is be able to update it without causing any loss of data in the dictionary.

All accesses to Leader must be made starting from this front page (shown below in its mock up version): whatever attempt to access a file of Leader without passing from this step first (say the "homepage" so to call it), will result in printing a message warning that there is not a valid session initialized, and no further contents will be shown in the accessed file (exit).

This is technical documentation and though doesn't mean to be complete, a description of the procedures currently triggered upon submission of the non mock up version of Leader follows:

• The form is submitted to a file named leader.php.
  Such file does:
  • Initializes the proxy. Then it saves to the $_SESSION php superglobal the password, username, host name (plus the used database name) in these variables:

    $_SESSION['proxyHost']
$_SESSION['proxyName']
$_SESSION['proxyPassword']
$_SESSION['database']
    This last one has, in its held value, the shape of: nativeLanguageName plus an underscore plus ForeignLanguageName: say english_italian, or italian_english, or dutch_chinese, etc..

    Saving into the session such values would not be required (and would be somewhat questionable otherwise, for security reasons perhaps) in an online environment, yet Leader is originally released as a package meant to be run on your own local disk: do you pose a security threat to yourself? Well, ok, let's go for the quip: at times a few do, and at times me too.
    
    Therefore, these values (which refer to the proxy login data) cannot be called in by any external file to be included (online standard procedure) because you yourself are passing such values in a form, and they do not exist otherwise in the local disk package because it is you who must tell the script which they are for your local machine PHP-mySQL package: thus the only way to save such data is to store them in the session (though writing a file with that data would have been conceivable, but if we are at that, a session seems a more rational, built in, and less dangerous stairway to that heaven then).
    
    If you want to build your own subroutines in order to add, for instance, drills to Leader, you can thus do it by setting up database connections using those variables for your mysql connections, thus bypassing any need to use the specific classes of my invention that I use throughout the files.
    If you think you have built interesting subroutines that can be nested as standalone interfaces, you can submit them to me via email and I will evaluate whether to add them in the search or drill interfaces: if I do, your name and website (if any) will be reported beside the search or drill option which calls in your procedure (if you browse this website you'll see I'm a decent guy and I pay acknowledgements indeed).
    
    All you would need to know or do beside that, is to inspect the file named database_structure.php to see what the structure of the database is, which is the only other thing you'd truly need to keep in mind and to know in order to build your own procedures.
    To have further information on the structures of those tables, please see the class in the file sqlHelpDesk.php.
  • Then the file determines the database name to be used.
    
    If the checkbox at the bottom of the login page, mentioned earlier, is checked, it scans a specific folder of the package to find a version text file which says which version is on your local machine.
    

    Roger Moore playing «Brett Sinclair» (right) and Tony Curtis playing «Danny Wilde» (left), surrender to an unknown evil villain who is more assuredly going to find his retribution pretty soon, in a The Persuaders installment, the Big Chill of my years as a teen staring in awe at the tv screen gulping pop corns and waiting for the beginning of their show. Wooow, go Roger, go with class! You show 'em now, Tony, don't you?!

    Forgery of such file is possible, but I still insist that I, so dumbly, cannot understand what advantage you might ever possibly get by intentionally compromising yourself - though I still remember when, once upon a time so many many years ago, when I was younger and happier and still as jobless as now, I got my very first PC, and after a week I started renaming all the folders into what seemed to me, hey man, definitely more user friendly names: that is, why the hack that antivirus folder wasn't just named antivirus? Didn't it make just plain sense? Sure as hell it did, so let's go for it. Yet, alas, once finished with this napoleonic idea of mine, a true Nietzschean «Revaluation of all values» of the e-age, I could find indeed all the folders faster, but I also found out my PC couldn't any more... Mh, needless to say I didn't make any rollback map of my enthusiastic changes... And so PC gone with the wind, babe.
    
    So: if Leader finds a version file, the first one grabbed will be the one from which the database name to be used has to be drawn (overwritten).
    
    It then includes a variable that carries the current database version (soon to be checked upon the one found in the version file).
    
    
  • It then proceeds to call in database_structure.php. This latest file includes all the definitions for the Leader database tables, with the exception of a few tables (in the list below flagged by a [x] sign): these latter are defined in another file named buildup.php.
    Leader's mySQL tables are currently the following ones:
    1. authors [x]
    2. cases
    3. countable
    4. declensions
    5. followers
    6. genders
    7. locations
    8. marks
    9. professions
    10. sources [x]
    11. literature [x]
    12. term
    13. term_cases
    14. term_countable
    15. term_declension
    16. term_follower
    17. term_gender
    18. term_location
    19. term_mark
    20. term_profession
    21. term_source
    22. term_type
    23. termcomments
    24. termcreated
    25. termdefinitions
    26. termerrordate
    27. termerrors
    28. termlastview
    29. termpronunciation
    30. termsynonyms
    31. termtranslations
    32. termupdated
    33. termviews
    34. types
    35. version [x]
    All these mySQL tables, with the exceptions of the table named literature which is composed of 5 fields (term id, example string, author id, source id, record id) and of the table named version which is composed by one field (and one record) only, are all composed of two fields, whose data type can vary, but whose field names and amount do not vary: in fact for each table they are two and they are laconically but maybe effectively named:
    1. id
    2. it
    Tables whose table name is composed by one single word are tables where the field id is a primary key.
    
    Tables whose table name is composed of one single word and such word starts with the prefix term, are tables that have an id which is a an id of a term (which can be repeated, so they are one to many tables) and an it field that is usually a textual field (varchar data type).
    
    Tables whose table names include an underscore(_) are many to many tables whose each field is a number indicating the id of a table whose id was a primary key.
  • At this stage a cute file named buildup.php is called in.
    
    This mammoth does the following:
    
    It compares the version from the version file with the one passed via leader.php.
    
    If they do not coincide (or obviously if no version file is found at all), it proceeds to build the mySQL database tables (each accordingly to its own table definition, obviously enough) for the given native/foreign languages pair.
    It only overwrites tables that do not already exist.
    
    It also populates the database as far as those tables that should already carry values (such as tables of categories for terms taxonomies) are concerned (they are the tables written in red in the SQL tables list above).
    
    All the tables are created only if the script checks they do not already exist, therefore if what is running is an update, no existing table will be overwritten and therefore no data loss would be entailed.
    
    Yet tables of taxonomies get always recreated from scratch in order to allow new data. I am aware this causes no loss of data and yet it could import important alterations in the connections between the existing terms and the related taxonomies identificative SQL primary keys, if the latter tables definitions get changed (for instance by adding or removing an entry, which may well displace all the previous table connections by shifting upward or downward their identificatives field values hosted within the id fields). We'll see in the future what can be done for this, whereas for the time being the solution is that new versions should never alter the tables of the existing taxonomies via removal of entries (adding new entries at bottom of an existing taxonomy table would be fine, and the presence of this last line of second thoughts like: "hey, I forgot to include an all important option, what are we gonna do now?!" is the only reason I kept in such potentially dangerous thing).
  • You are from there redirected to a file named choose.php

The add file looks as follows, and I will describe shortly what it does in detail (In general, allows to record a new term):

• As you may notice in the tabulation labeled as Show Step 2 there are several drop down menus, each hosting a great deal of options (moreover, you can select multiple options, thus yielding truly a lot of possible combinations): with them you can attach to each term a lot of additional data that describe it (if you want so). You have to become familiar with these options, and though I concede they seem too many, yet the advantage is that you can truly label each term in highly specific ways, with the advantage that it is rather unlikely that you will not find there at least acceptable accommodations for nearly every type of term labeling you may fancy.
• The add.php file calls in add_run.php.
• add_run.php checks whether the new term to be added already exists, or if no term was passed (empty string or a sequence of spaces). If so it prints a message and exits.
  
  If a term is passed, each $_POST superglobal variable value is scanned, tags are removed if any, it is trimmed of leading and trailing whitespaces, all whitespaces that are duplicated (that is, two or more whitespaces in a sequence) are turned into one whitespace only (this all grants consistency with searches: an interlooping or overlooked additional whitespace may make a search fail, for in computing nearly a match means no match at all).
  
  Then a whole new record, shaped after the inputs provided in the html form at add.php, is added (inserted) accordingly to the database available tables and to their structure.
• The update interface will look exactly like this one meant to add a term, so I won't reproduce the update interface here, with the difference that the update interface, when submitted, would not add a new term, but would simply update the already existing term.
  
  For those interested in technical issues, with the updating process has been involved a decision I want to account for and that you might find interesting if scripting issues are either your hobby or profession.
  
  How to perform an update in an environment where the involved tables per each update are several dozens as in Leader?
  This is a twofold issue, that can be addressed in two ways:

  • Update only the fields which are actually changed by the user when he/she modifies the fields in the update interface.
  • Alternatively, just do this:
    • Delete all the records.
    • Insert as brand new all the (by now modified) records.

  By all means, logics would suggest the first approach.
  Yet Leader follows the second one: why?
  
  Let's imagine this frequent situation on many websites: an online user profile with many fields (birth, name, nickname, email, profile, preferences, residence, status, addresses, phone numbers etc...).
  The user chooses to update it.
  
  The database is queried and the user is presented with all his/her current values for all the fields.
  Now, say just a couple of these fields get changed (updated) by the user.
  The changes, along with the unmodified fields, are then submitted to the server.
  So far so good.
  
  If now I opt to use an updating procedure for the fields on the database side, the server has a significant amount of work to do: it has to scan, say, the $_POST superglobal (or $_GET, let's forget the details now).
  Also, it has to have saved somewhere else the original values that the field held before the update, say in $_SESSION - unless I want to... re-query the database so to get twice from the database what I already had: in fact in order to populate an update interface, I already had to query the database and retrieve from it the data so to show to the user his/her current field values and present them to his/her possible modifications.
  
  Php must now compare the older session values against the newly submitted ones and determine which fields have changed, and consequently update only those ones.
  
  Also if you don't have experience in the job, you can sense the burden for the Php engine, and for the server RAM memory, if a field that must be checked for possible modifications so to determine whether it has to be updated or whether it was left unmodified, is a so called blob sql field namely one that can carry several tens of thousands of bytes of data.
  
  Of course, one may argue: just update anyway, and insert only if you don't find a record at all for any given $_POST entry.
  Unfortunately, as far as I can see it, it can't be that simple: we still have to compare the $_POST with the relative $_SESSION before deciding anything: in fact, it is possible that the $_POST array, which carries the newly possibly modified values, exceeds in size its relative $_SESSION that carries the original values (which means: the user has added fields that he/she previously didn't fill in; thence: insert them as brand new), or vice versa the $_SESSION array could be bigger than the $_POST array (which would mean: the user has deleted fields that where there, thence find and delete those). And then for all the rest we have to perform the comparisons so to verify whether unto them we're to use update or to leave the sql field as it was in its original version, untouched (because it was not updated at all by the user).
  
  Not only, but even if the two arrays ($_POST & $_SESSION) would be identical in size, we'd still have to perform comparisons on the all of them in order to ascertain whether anything was changed, right?
  
  Now, it is argued that a process that shifts this obvious burden to the SQL and frees the Php engine of all these checks, namely a process that just deletes all the records without performing any comparison, and which just reinserts the submitted values as, say, brand new ones, is somewhat asking to SQL to bear the brunt of a heavier process that it would not be really needed or required from the database end of the application process: in fact the sql database would undergo changes also for fields that were not modified (updated).
  Not wrongly, some might see this somewhat dysfunctional, or debatable.
  
  It's clearly a trade off, like we have many for instance in economy between demand and supply.
  I opted, with Leader, to let the SQL database rather than the Php engine to bear this burden. "Someone" had to, anyway.
  
  Maybe it's not the most elegant solution, because it cuts a long story short, and you just can't be brutal and elegant in the same twist.
  But it has the advantage that, delivering to SQL a burden that has to be accounted for anyway, it makes the Php codes much more manageable.
  I wanted to account for this choice, without any claim that it was necessarily the best one: after all, it entirely relies upon this confidence: that SQL will keep its indexing performances more oiled, and thus faster, than what Php would be able to do as far as performances are concerned when having to deal with all those checks.
  
  Wrong, right?
  It's a trade off and I am not aware of data that ever measured this issue (though such data might well exist somewhere).
  So either wrong or right, that was the decision that was made, based on those considerations. If then it comes out that Php would have been faster, I will accept the critique. But at least credit me with the fact that I posed this problem to myself and I tried to make some reasonings about it. I could be wrong, yet it seems to me the solution I adopted is not entirely irrational. And that's all I meant to say, or to account for. A matter of intellectual honesty requested to me to make this solution transparent in the path that led to it.
  
  PS: since Leader Sql tables are normally composed of just two fields, and since an update process implies that the term that has to been updated will not change (what changes are its related fields), obviously enough no deletion and re-insertion of the term will ever be performed, but only of the fields connected to it and that, so to say, stem from it like radiating rays ( = many to many sql tables).

Once the terms have been added, they are searchable.

The interface for the searches, which is likely to undergo changes so to allow gradually for more different types of searches, is this:


I can show to you a mock up interface of what is returned after a search. The layout can be considered temporary, though it would not become much more complex over time.
The example provides a mere example: if you click the links you will see how the details can appear. I insist: this is a mock up to give you an idea of what can be done querying a Leader database:



As for the interface for the drills, the following is the basic drills menu, to which many further modules for many other drills might get added:



Eventually, an example result of a drill can look like this (in a Leader installation that is about italian versus english; the drill is set to prompt terms in english so to have their answers in italian - of course it could have been set vice versa; also, the check answers button is disabled in this example):



A slide show drill looks like: