3 ms·

> Names Don't try to force schemas onto schema-less data. Store the "name" as a JSON string/blob representing the various possible attributes (given, middle, f

> Names Don't try to force schemas onto schema-less data. Store the "name" as a JSON string/blob representing the various possible attributes (given, middle, family, title, etc) and provide a variety of functions for representing that data. IF you really need to do this at all (for an internal app, you probably don't). > Physical links Include an Hardware Asset FK in your Link M2M table. Model each binary link explicitly, so a Y cable = 2-3 different Links that point to the same cable Asset. Or you can have single Links with M2M inputs/outputs. But definitely don't model Y cables explicitly. > Password recovery What is so complicated about this, specifically? Python and Ruby are completely different languages with no guarantees for interop.

deelly 4y ago
I could be wrong but using JSON as format for name is not a solution, its abstraction over possible solution. Suppose we store all names as JSON structure. Question - how people will create such structure from their names? Using form with dozens of fields and checkboxes? Second question: how we will display this structure? We have to find a way to convert this JSON into string to show name. And as result we will surely need function to convert this shown strings into JSON for sure. And how we can solve issue when some names could be presented as a bit different JSON structures? And how we can validate that these slightly different JSON structures are equal?
shkkmo 4y ago
Your solution assumes atleast a dozen incorrect things from the classic https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
- pphysch 4y ago
  That's strange, because my one (1) assumption is that the name can be represented as a schema-less dictionary of zero or more Unicode strings. Heck, one of those strings could be an ID for a bitmap or SVG of their non-textual "name". If you can't do that, you have more pressing issues. Where are you getting "a dozen assumptions" from?
perlgeek 4y ago
> Include an Hardware Asset FK in your Link M2M table. Model each binary link explicitly, so a Y cable = 2-3 different Links that point to the same cable Asset. Or you can have single Links with M2M inputs/outputs. But definitely don't model Y cables explicitly. Our cables have stickers with cable IDs, which are stored in the CMDB (and can be used to trace the endpoints through patch fields, for example). So if you model a Y cable as two physical cables, you have to both allow duplicate cable IDs AND multiple cables per port. Both of these have significant downsides in preventing data entry errors.
- 7thaccount 4y ago
  Can't you just have 2 tables? One for 2 end and one for 3 ends?
  - wintermute2dot0 4y ago
    Or just have a cable type column (which could be a pointer/foreign key back to a table of cable types, so you can add the cable with 4 ends that comes out next year).
    - 7thaccount 4y ago
      Yeah that sounds even better and what I typically see in production databases
- pphysch 4y ago
  > So if you model a Y cable as two physical cables No. Model it as two abstract "Physical Links" or "Connections" which FK to the same physical cable Asset, which is uniquely determined by its inventory ID and/or manufacturer model+serial. If a Link needs to know whether its part of a Y cable Asset, it can join the Asset table. If a Y cable Asset needs to know what it's connected to, it can join the Link table. Additionally, you have a nice clean Link table for doing graph traversal (get me everything connected to this impacted Asset by degree <= 2), and a nice clean Asset table for inventory tracking.

deelly 4y ago

I could be wrong but using JSON as format for name is not a solution, its abstraction over possible solution. Suppose we store all names as JSON structure. Question - how people will create such structure from their names? Using form with dozens of fields and checkboxes? Second question: how we will display this structure? We have to find a way to convert this JSON into string to show name. And as result we will surely need function to convert this shown strings into JSON for sure. And how we can solve issue when some names could be presented as a bit different JSON structures? And how we can validate that these slightly different JSON structures are equal?

shkkmo 4y ago

Your solution assumes atleast a dozen incorrect things from the classic https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

pphysch 4y ago
That's strange, because my one (1) assumption is that the name can be represented as a schema-less dictionary of zero or more Unicode strings. Heck, one of those strings could be an ID for a bitmap or SVG of their non-textual "name". If you can't do that, you have more pressing issues. Where are you getting "a dozen assumptions" from?

perlgeek 4y ago

> Include an Hardware Asset FK in your Link M2M table. Model each binary link explicitly, so a Y cable = 2-3 different Links that point to the same cable Asset. Or you can have single Links with M2M inputs/outputs. But definitely don't model Y cables explicitly. Our cables have stickers with cable IDs, which are stored in the CMDB (and can be used to trace the endpoints through patch fields, for example). So if you model a Y cable as two physical cables, you have to both allow duplicate cable IDs AND multiple cables per port. Both of these have significant downsides in preventing data entry errors.

7thaccount 4y ago
Can't you just have 2 tables? One for 2 end and one for 3 ends?
- wintermute2dot0 4y ago
  Or just have a cable type column (which could be a pointer/foreign key back to a table of cable types, so you can add the cable with 4 ends that comes out next year).
  - 7thaccount 4y ago
    Yeah that sounds even better and what I typically see in production databases
pphysch 4y ago
> So if you model a Y cable as two physical cables No. Model it as two abstract "Physical Links" or "Connections" which FK to the same physical cable Asset, which is uniquely determined by its inventory ID and/or manufacturer model+serial. If a Link needs to know whether its part of a Y cable Asset, it can join the Asset table. If a Y cable Asset needs to know what it's connected to, it can join the Link table. Additionally, you have a nice clean Link table for doing graph traversal (get me everything connected to this impacted Asset by degree <= 2), and a nice clean Asset table for inventory tracking.