It is a matter of opinion. You might use postfix representation (à la RPN, or even some stack-oriented programming language), or some bytecode (specific to your expression language), or some s-expr syntax, if you want some more compact representation. JSON is probably a less compact textual representation but it is very widely used (and you've got many libraries to parse JSON); you could define your JSON format for your expression ASTs.
You could also store a compressed form of your formula's representation in your database.
You might consider using some bytecode of some existing interpreter, e.g. Lua, Guile2, or even some JVM class with your own class loader, etc...
And perhaps you want to store closures, not expressions.
You may want to embed an interpreter inside your application.
You need to learn more about programming languages (e.g. read Scott's book: Programming Language Pragmatics), compilers (read the dragon book) & parsing & interpreters & semantics ; if you know a bit of Scheme or Lisp (and learning it thru SICP is not a loss of your time) I strongly recommend Queinnec's book Lisp In Small Pieces, giving a broad view of interpretation & compilation techniques.
MathML is a standard for representation of mathematics, notably formulas (using XML). But it is not compact and not easy to parse, so very probably overkill to represent expressions.
OpenDocument is a standard for spreadsheet & word processing documents, so contains a notation for expressions (apparently related to MathML).
You can use some DBMS (from sqlite to PostgresQL, MongoDB, MariaDB/MySQL) to store your formulas (as TEXT or BLOB in SQL sense), you'll be able to store millions or billions of them (e.g. have some SQL TABLE containing them, one row per formula).
Don't forget to document the format of your persistent data, and the form of the "expressions" and/or "closures" in it. Even your advanced users could need to know that format and use it in some other way without having to reverse-engineer it.
Perhaps you are re-inventing business rule management systems or expert systems (look into CLIPS & JESS) or some scripting language (then perhaps try to use an existing one, not invent your own) or spreadsheets ...
I don't see any risk in storing your formulas as text, provided you define and document very well the syntax of your formulas (e.g. using EBNF) and their semantics (e.g. an operational semantics); publish that documentation (advanced users would need to know about them). Parsing efficiently short formulas is not a real issue (the disk I/O or database access would probably be the bottleneck, more than the parsing of the formula) : you can write a simple recursive descent parser or use a parsing expression grammar. Evaluating a formula is more difficult (and requires a semantics, and some evaluation strategy). You'll need some environment to deal with your variables and their binding! Read also about higher-order abstract syntax. Don't forget to validate a formula before storing it.
You might even take a metaprogramming approach and translate these formalas into a routine (or a method, or a class, etc...) or something runnable...
