4 ms·
I'm not arguing about storing serialized format; instead I suggest to parse it and end up with something like that: NAME ( 1, "Fyodor Mikhailovich Dostoyev
by Mikhail_Edoshin 7y ago
I'm not arguing about storing serialized format; instead I suggest to parse it and end up with something like that:
NAME ( 1, "Fyodor Mikhailovich Dostoyevsky" )
TAG ( FIRSTNAME, 1, 0, 5 )
TAG ( LASTNAME, 1, 20, 30 )
TAG ( PATRONYMIC, 1, 7, 18 )
I'm not saying it's efficient (UPD: speedy), but it's sufficient to get the required details and can be mechanically transformed into a more efficient form. UPD: And it's very flexible and easy to extend. I believe it can handle just about any kind of naming from "Falsehoods about names".
- goto11 7y agoBut why include all the cruft fist place? You could just save this information (in normalized form): FIRSTNAME: Fyodor LASTNAME: Mikhailovich PATRONYMIC: Dostoyevsky
- Mikhail_Edoshin 7y agoThis one lacks ordering. It's not a problem for Russian names as the rules are fixed, but may be a problem for other ones. And how would it scale? E.g. John Ronald Reuel Tolkien and George Herbert Walker Bush have two middle names, while full name of García Márquez is Gabriel José de la Concordia García Márquez. Markup handles this uniformly creating only as few metadata records as necessary, but a field-based model will need fields for all of this that will stay empty most of the time and likely some meta fields to set additional quirky flags.
- goto11 7y agoRegardless of how complex naming schemes you need to support, you just make it more complex and harder to query by storing tag names and character indexes and whatnot.