Hacker News Reader

Comment by pphysch | Hacker News Reader

> 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.

View on HN

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

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?

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?

> 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.

Can't you just have 2 tables? One for 2 end and one for 3 ends?

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).

Yeah that sounds even better and what I typically see in production databases

> 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.

Reply on news.ycombinator.com