Arnaud Bouchez

For a regular SQL DB, I would use a BLOB SUB_TYPE TEXT field, to store the JSON content. Then duplicate some JSON fields in a dedicated stand-alone SQL field (e.g. a "id" or "name" JSON field into regular table.id or table.name fields in addition to the table.json main field), for easy query - with an index if speed is mandatory. So, start with JSON only (and a key field), then maybe add some dedicated SQL fields for easier query, if necessary. side note: I would rather use SQLite3 or PostgreSQL for efficiently storing JSON content: both have efficient built-in support. Or a "JSON native" database like MongoDB.

I don't agree - don't add new private methods. It is not SOLID. Try to keep the class definition small and readable. Rather add a hidden object or class in your implementation section.

Our Open-Source https://github.com/synopse/mORMot/blob/master/SynCrypto.pas has almost all that you require. About performance, it is the only one in the Delphi area using AES-NI and optimized SSE3/SSE4.2 assembly - as far as I know. So it should blow alternatives. It is cross-compiler (Delphi and FPC) and cross-platform (Windows, Linux, BSD... thanks to FPC). For elliptical curves, see its sibbling https://github.com/synopse/mORMot/blob/master/SynEcc.pas It supports only secp256r1 but it is feature complete (e.g. simple CA management) and fast (1 ms to create a key pair, 0.4 ms to sign or verify on x86-64) - also cross-platform and cross-compiler. See the documentation at https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_187 Both are highly maintained, and used on production since years. They don't require any external dll (like OpenSSL) which tends to be a maintenance nightmare on Windows.

Yes, @Bill Meyer is right: do not put the nested functions part of the main class. It would break SOLID principles for sure - at least the single responsibility. Always favor composition in OOP. About refactoring and breaking huge functions, you could take a look at those slides: Following these proposals, for code refactoring, I would move the code into dedicated records with methods (or classes).

Switch to a n-Tier architecure is the way to go. Keep the database locally on your server computer (or network), then use regular REST/JSON over secure HTTPS for the communication with clients. HTTPS will be much easier to secure and scale than forcing encryption with the database driver. Certificate management is a difficult think to do - I have seen so many solutions running fine... until a certificate becomes obsolete. 😉 We usually use a nginx server as reverse proxy, with https://letsencrypt.org/ certificate management.

A quick and simple rule would be to define only mandatory variables as shared for the nested procedures, i.e. above them. That is, try to keep all variables of the main block in the lower part of the code, just before the main block. Just as you did. From my experiment, nested functions are fine if there is only 1 (or 2) of them. Once I reach the number of 2/3 nested functions, I usually define a private record type, with proper methods. It is kept private in the implementation section of the unit. The trick of using a record with methods, and not a class, allows to allocate it on the stack in the main method, with no try..finally Free block. It is much cleaner (more SOLID), and also much more extendable. The main benefit is that it is re-usable: you could reuse some code, in another function. Last but not least, you have the possibility to add a unitary test method, and browse easier the code in your IDE.

with SomeUnitName do doesn't compile on my Delphi 10.3 (nor FPC). Compiler complains with [dcc64 Error] Test.dpr(200): E2029 '.' expected but 'DO' found

@Bill Meyer Is with UnitA, UnitB do even suppose to compile?

What is sure with "with" discussion is that it is a trolling subject in the Delphi community since decade(s). For instance, the topic is about "with" in general, and that @Yaron stated that the IDE debugger has troubles with it. TRect came as a true problem about "with" - I do agree with Stefan. But problem came from Embarcadero, not taking into account existing code base. Just like ARC, or the AnsiStrings... Most dev people outside this forum would argue, paraphrasing @Dalija Prasnikar, that 'Delphi is a relic of another time and another coding practices: for instance, there is no GC !'. Php adepts would argue that writing $this->foo is much cleaner/safer than what Delphi (and other languages) do about properties. I like "with" - when properly used for two-liners code - as I wrote. It is a clean way of writing code, "making it easier to read" as wrote Yaron. Similarly, I like "object" more than "record with methods", since it allows easy inheritance - when using high-performance code with pointers and pre-allocated memory buffers/arrays. Of course, with only static methods. This was just my 2 cents, to introduce another POV into the discussion. Nothing is totally black nor white.

Breaking compatibility by adding properties is very likely to break code... My assumption is that you use and maintain your own classes. This was not my point. I didn't mean CarWheel for sure. Wheel, Engine and Drive are fine. a, b and x aren't. And I wouldn't use "with" over two TCar instances, or two classes with a Wheel property. But it would have sense, say e.g. to write something like: with currentCar do CarInfo.Caption := format('Engine %s with %d wheel(s)', [Engine.ModelName, Wheel.Count]); My point was that "As everything powerful can be armful when misused, I like "with", when it is not over-abused". If the "with" scope is small enough to be obvious and safe, fine. Otherwise, use local variables.

As everything powerful can be armful when misused, I like "with", when it is not over-abused. For instance, I like "with", when it has only several lines of scopes. It does make sense to me, when used for a single line. Otherwise, I switch to an implicit local variable: asm generation would be the very same. If you think "with" should be avoided due to its implicit context switch, I guess next step would be to force using self.foo for class properties... just like the $this->foo of Php... what a progress! 🙂 I am against any new warning at compiler level. And if you are confused by with someclass do x := a * b and don't know to which class a, b, or x belongs to, it is time renaming the properties/functions to something more explicit!

From the relaxed JSON website: I still don't get what a "JSON number" is - from its json.org definition, it is any kind of number with none to any decimals...

The worse about Relaxed JSON is that it is not reversible. It may change the values. For instance, { number: 1.0 } will become { number: 1 } which is not the same. So for an exchange format, I would never use Relaxed JSON. For a settings local file, edited via vim or nano - why not? but as @David Heffernan stated, YAML (or TOML) sounds like better candidates.

The mORMot parser supports "extended JSON", as used with MongoDB: field names can be without quotes. It follows in fact the JavaScript object declaration syntax. Internally - between mORMot client and server - it will use it to slightly reduce size and enhance performance. For regular clients (e.g. JavaScript), it will server standard JSON with quoted field names. As @Lars Fosdal states, a rigid format seems better when exchanging data between heterogeneous ends.

List of ingredients are stored in at least two MicroServices: the "Pizzaiolo" service (which prepare the pizza) and the "accounting" service (which take into account the ingredients stock, and order them if needed). You may put the list of ingredients in the "Menu" MicroService... if you want to generate an accurate menu. Each service may need additional information: the Pizzaiolo would need to have the weight of each ingredient per kind of pizza, the accounting service may have delivery information, and the menu just need the name...