Una posibilidad sería almacenar todas las variantes que cree que podrían ser útiles como un elemento de matriz, ¡aunque no estoy seguro de si eso podría ser posible!
{
"number" : "pl",
"surface_form" : "skrejjen",
"surface_forms: [ "skrej", "skre" ],
"phonetic" : "'skrɛjjɛn",
"pattern" : "CCCVCCVC"
}
Probablemente también sugeriría no almacenar formularios de 1000 palabras con cada palabra, sino cambiar esto para tener documentos más pequeños. Cuanto más pequeños sean sus documentos, menos tendrá que leer MongoDB en la memoria para cada búsqueda (siempre y cuando las condiciones de búsqueda no requieran un escaneo completo, por supuesto):
{
"word": {
"pos" : "N",
"lemma" : "skrun",
"gloss" : "screw",
},
"form" : {
"number" : "sg",
"surface_form" : "skrun",
"phonetic" : "ˈskruːn",
"gender" : "m"
},
"source" : "Mayer2013"
}
{
"word": {
"pos" : "N",
"lemma" : "skrun",
"gloss" : "screw",
},
"form" : {
"number" : "pl",
"surface_form" : "skrejjen",
"phonetic" : "'skrɛjjɛn",
"pattern" : "CCCVCCVC"
},
"source" : "Mayer2013"
}
También dudo que MySQL funcione mejor aquí con búsquedas de formas de palabras aleatorias, ya que tendrá que hacer un escaneo completo de la tabla como lo haría MongoDB. Lo único que podría ayudar allí es un caché de consultas, pero eso es algo que podría construir en su UI/API de búsqueda en su aplicación con bastante facilidad, por supuesto.
