0

I am creating a logging system using MySQL and SQLite with the goal of maximum optimization. This has resulted in a monstrosity of a table structure which breaks the first normal form due to its repeating groups. Here's what I mean by this:

The format of a log in this system looks similar to this:

{1} used tool {2} on a {3} created by {4}

Each {X} is replaced with relevant information to create an informative log on the client. This allows for translating logs into different languages. My original idea was to break the first normal form and use repeating groups to store these replacements.

Here's an example of a processed & replaced log which would be shown to the client:

Jeff used tool remover on an entity created by Steven

The information that replaced the placeholders is stored in the replacement_X_... columns that are shown in the screenshot above.


Advantage: This, as far as I know, should be faster than using a separate table to store the replacements which would require joins or even multiple SELECTs.

Advantage: This structure is friendly for a search feature

Advantage: This structure allows for quick INSERTs, which there are a lot of!

Disadvantage: There is a maximum amount of replacements that are possible, in my case above, six, rather than a variable amount

Disadvantage: Breaks the first normal form, uses repeating groups and is generally just really ugly and difficult to make & process queries for


Is breaking the first normal form, in this case, justified? Or is there a better way of going about this which won't hinder performance and is also appropriate for both MySQL and SQLite?

Billy
  • 93
  • 10
  • 1
    I'm not seeing how any normal form is being broken here. If you are storing different points of data for different languages you need to support, then there is not repetition of data per se. Denormalized databases tend to suffer from repetition of data; show us where/how that is happening. – Tim Biegeleisen Oct 14 '18 at 14:33
  • @TimBiegeleisen Thanks for your comment, did you open the screenshot that I linked above?: [Image](https://i.venner.io/chrome_2018-10-14_15-07-00.png) – Billy Oct 14 '18 at 14:36
  • 2
    That screen shot is illegible, and no one is going to look at it. Please include supporting information directly in your question. – Tim Biegeleisen Oct 14 '18 at 14:40
  • Why does it bother you that your db structure may break a normal form? – Shadow Oct 14 '18 at 14:49
  • @Shadow Hmm, well that is not really the main concern - the table structure is ugly and inconvenient, and I'm wondering whether there is a better solution to the problem – Billy Oct 14 '18 at 14:54
  • That means that the only problem you have that it 8s not flexible enough. You either need t o normalise the data or use flexible storage within a field e.g. json or xml. – Shadow Oct 14 '18 at 15:16
  • Hi. Please [use text, not images/links, for text (including code, tables & ERDs)](https://meta.stackoverflow.com/q/285551/3404097). Use a link/image only for convenience to supplement text and/or for what cannot be given in text. And never give a diagram without a legend/key. Use edit functions to inline, not links, if you have the rep--make your post self-contained. – philipxy Oct 14 '18 at 18:16
  • 1
    [How can you represent inheritance in a database?](https://stackoverflow.com/q/3579079/3404097) The inheritance relationship here is subtyping with DBMS types as subtypes, so metadata tables are using one of the idioms available to users. But also EAV is used for this. So besides the application subtyping notions learn about pros & cons of [EAV](https://stackoverflow.com/a/23950836/3404097). For a log the straightforward relational solution has a table per type & the typical SQL solution is a column per type with exactly one non-null. PS "Normalized" doesn't mean "well designed". – philipxy Oct 14 '18 at 20:45
  • Thank you @philipxy, very informative – Billy Oct 16 '18 at 08:26

0 Answers0