I don't know if this is how it's currently implemented, but it seems likely.
Current case is a "Notes" table with fields for character id and text, possibly using the character id as the primary key.
the change you suggest might be implemented as a table with fields for note id, character id, title and text, with note id as key, and maybe an index on character id (pretty small table though). Use two screens in the app, one which selects all notes with character id = you, and displays titles - then the existing screen to edit/manage the note.
Pretty easy, really. Might want to set limits on how many notes a character can have, but it could be pretty generous.
As an aside, do "PHP" and "expert" belong in the same sentence? (Just kidding! *runs and hides*)
Current case is a "Notes" table with fields for character id and text, possibly using the character id as the primary key.
the change you suggest might be implemented as a table with fields for note id, character id, title and text, with note id as key, and maybe an index on character id (pretty small table though). Use two screens in the app, one which selects all notes with character id = you, and displays titles - then the existing screen to edit/manage the note.
Pretty easy, really. Might want to set limits on how many notes a character can have, but it could be pretty generous.
As an aside, do "PHP" and "expert" belong in the same sentence? (Just kidding! *runs and hides*)