het probleem is dat dit wel degelijk taalafhankelijk is.
Als je dit in C++ wilt doen bv. zal je al functiepointers (adressen) moeten opslaan, en dan zit je met het immense probleem dat je je programma nooit mag hercompileren

. Dus ik zou zeggen dat het enkel in interpreted languages of via reflection mogelijk is.
In dat geval ben je in principe genoeg met het opslaan van de namen van de functies en de parameters (eventueel de types in typesafe languages).
Zeer volledig zou afaik zoiets zijn:
tabel functies (naam, id)
tabel body (functieid,parameterid, volgorde)
tabel parameters (id, type)
gelinkt als volgt:
functies (1)<->(0..n)body(1)<->(1)parameters
Dit is natuurlijk zwaar overdreven gesplitst om persistentie te verzekeren, praktisch zal je parametertype wrsch wel in body steken. merk op dat je per overload een nieuwe functie aanmaakt (functienaam is dus niet uniek ofzo). Eventueel kan je natuurlijk extra zaken als namespaces/packages gaan toevoegen, maar dat zijn details ofcourse.
Dan deze tabellen:
systeem (id, naam, extra_info)
implementatie (systeemid, functieid, volgorde)
parameter(id,value,implementatieid,boolean functionresult, volgorde)
gelinkt:
systeem(1)<->(1..n)implementatie(1)<->(1)functies
implementatie(1)<->(0..n)parameter
analoog aan voorgaande, je kan natuurlijk weer enkele tabellen schrappen ten koste van persistentierisico en denormalisatie

.
ivm parameter: value zit hierin, maar dit kan natuurlijk ook een berekend resultaat zijn, dan steek je in value bv. het nummer van de functieaanroep ofzo, dat is zelf wat zoeken.
let wel op dat in implementatie en body de parameter volgorde essentieel is. Je moet dus zorgen dat deze uniek is (logische manier is bv. in body de key (functieid,volgorde) primary te maken).
Dat is dus hoe ik het algemeen zou doen voor interpreted zaken.
Reden dat ik het functies gedeelte quasi volledig splits en zo sterk normaliseerde is omdat dit een vrij cruciaal gedeelte is. Je wilt dat je parameters correct zijn en je wilt dat er niet per ongeluk system calls in je db steken (stel je voor dat mensen in een php omgeving toegang hebben tot exec).
Hoe je het specifiek afhandelt is zéér taalafhankelijk, maar in principe zal je al beschikken over een array/vector/lijst/collectiontypenaarkeuze die in goede volgorde je uit te voeren statements + parameters beschikt. In pakweg php komt het er dan nog maar op aan eval aan te roepen. Natuurlijk komen er extra's bij zoals kijken of parameters kloppen, zorgen dat resultaten worden bijgehouden en aan een id (volgorde) worden gelinkt indien ze weer nodig zijn, maar dit hangt zeer sterk af van hoe je systeem werkt

. In php parse je dat gewoon (bv. $result[$volgorde] = ...), in java zal het iets anders zijn.
edit: dit is wat ik interpreteerde dus, kan zijn dat ik wat naast jouw idee zit, maar ik hoop dat je het al een of ander beeld geeft.