5

A db with several hundred tables will usually have more then few enums/sets defined in it.
How do you synchronize you PHP code with the enum values, to avoid using string literals in your code (which we all know it just seems easier, but in the long run causes stupid bugs).
The only good solution I can think of is using, during the build of the project, a process which will generate constants for all the enums in the DB, or, create and compile a PHP extension with those values.
Any different, better solutions out there?

ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257
Itay Moav -Malimovka
  • 52,579
  • 61
  • 190
  • 278
  • 1
    When you asked this question [you licensed it as CC BY-SA 2.5](https://stackoverflow.com/help/licensing). You cannot revoke that license. Please stop vandalizing your question. I agree that the marked duplicate is not a good duplicate and have voted to reopen your question on that basis. – ChrisGPT was on strike Apr 21 '21 at 01:17
  • 1
    And please note that we have an [official code of conduct](https://stackoverflow.com/conduct). Some of the language in both of your most recent edits is not appropriate. Be nice. – ChrisGPT was on strike Apr 21 '21 at 01:20
  • @Chris don't you find it sad that that was the only way I could get this right? I agree there has to be another way and I will be happy to use it, if it is a way that works. – Itay Moav -Malimovka Apr 22 '21 at 11:54
  • Well you could have added a short blurb explaining why the dupe wasn't appropriate to your existing question. That would have put it into the reopen queue and likely resulted in a reopen much sooner. Completely replacing your question with a short rant isn't likely to help, and in fact I completely _missed_ the fact that this was closed with a bad dupe when I reverted your first edit. – ChrisGPT was on strike Apr 22 '21 at 12:44

1 Answers1

3

As Plato would say: either PHP and SQL are independent, or SQL is generated from PHP, or PHP is generated from SQL, or both are generated from the same source.

The first is usually unacceptable if there's a lot of changes happening, but otherwise quite stable.

The second is what happens with a lof of recent solutions that manage your SQL from the PHP side (and gracefully handle schema changes from the PHP side as well). This means your mad SQL ninja skills might be useless and frustrating.

The third is what you suggest. It's fine as long as you can manage the "generated during build" part without stepping on the toes of your source control system and your package system. Having a clean build system helps (which is somewhat unusual in PHP).

The fourth involves adapting an existing database modeling tool to generate both the SQL schema and the PHP code. This way, you would simply work with the tool once every two weeks, generate both PHP and SQL, and commit the result. Adapting the tool, however, can be quite nasty (then again, you can try to look for an XML export and work from there).

Victor Nicollet
  • 24,361
  • 4
  • 58
  • 89