Test article - table issue

| **Identifier**      | **Creator**                     | **Advantages**                                                                                           | **Disadvantages**                                                                                   | **Unique Features**                                                                                            |
|---------------------|---------------------------------|-----------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|
| **ULID**            | A. Feerasta                     | - Lexicographically sortable<br>- 128-bit compatibility with UUID<br>- Easily implementable in many languages | - Not natively supported in most databases<br>- Requires additional logic for collision avoidance  | - Provides monotonicity within the same millisecond if properly implemented                                      |
| **LexicalUUID**     | Twitter                         | - Ensures lexicographical ordering<br>- Ideal for ordered database indexing                                | - Requires custom implementation<br>- May not be as universally recognized or supported as UUIDs    | - Specifically designed to work well with systems that benefit from ordering, such as databases and queues      |
| **Snowflake**       | Twitter                         | - Highly scalable and distributed<br>- Time-ordered<br>- No central coordination needed                   | - Complex to implement correctly<br>- Limited to 4096 IDs per millisecond per node                  | - Combines time, datacenter, machine, and sequence numbers to ensure uniqueness across distributed systems      |
| **Flake**           | Boundary                        | - Similar to Snowflake, provides time-ordered and distributed IDs<br>- Useful in distributed systems        | - Can be complex to manage across different nodes<br>- Requires consistent clock synchronization    | - K-ordered IDs are well-suited for systems where time-based ordering is critical                                |
| **ShardingID**      | Instagram                       | - Facilitates sharding in distributed databases<br>- Reduces collision risk across shards                  | - Implementation complexity<br>- Requires precise control over ID generation                        | - Helps with the horizontal scaling of databases by ensuring unique identifiers across shards                   |
| **KSUID**           | Segment                         | - K-sortable, allowing for lexicographical sorting<br>- Embedded timestamp<br>- 160-bit, ensuring higher uniqueness | - Larger size than standard UUIDs<br>- Not as widely adopted or supported as traditional UUIDs        | - The longer bit length provides additional uniqueness and future-proofing                                       |
| **Elasticflake**    | P. Pearcy                       | - Tailored for use with Elasticsearch<br>- Time-ordered and distributed                                    | - Limited to specific use cases like Elasticsearch<br>- Less flexible for general-purpose applications | - Integrates well with Elasticsearch, providing efficient querying and indexing                                  |
| **FlakeID**         | T. Pawlak                       | - Simple to implement<br>- Time-ordered and scalable                                                       | - Fewer features compared to Snowflake<br>- Potentially limited to certain environments             | - Focuses on ease of use and simplicity while retaining core benefits of time-ordering                           |
| **Sonyflake**       | Sony                            | - Optimized for low-latency networks<br>- Time-ordered<br>- Scalable and distributed                       | - Limited to environments with low network latency<br>- Requires consistent clock synchronization    | - Designed for performance in low-latency environments, making it suitable for high-speed transactional systems  |
| **orderedUuid**     | IT. Cabrera                     | - Ensures time-ordered UUIDs<br>- Useful for ordered databases                                             | - Requires custom implementation<br>- May not be as widely recognized or supported as UUIDs         | - Provides the benefits of traditional UUIDs while adding ordering based on creation time                        |
| **COMBGUID**        | R. Tallent                      | - Combines timestamp with randomness<br>- Compatible with standard UUID formats                            | - More complex to implement<br>- Less intuitive for general use                                     | - Enhances traditional UUIDs by adding time-based components for better sorting                                  |
| **SID**             | A. Chilton                      | - Sequential ID generation<br>- Useful in systems where order matters                                      | - Limited flexibility<br>- Not suitable for distributed systems                                      | - Ensures that IDs are generated in a strictly sequential manner, useful for single-system environments          |
| **pushID**          | Google                          | - Time-ordered<br>- Designed for real-time databases<br>- Short and unique                                 | - Limited to specific environments like Firebase<br>- Smaller address space compared to UUIDs       | - Optimized for real-time applications, particularly in Firebase for efficient and unique key generation         |
| **XID**             | O. Poitrey                      | - Compact size (12 bytes)<br>- Easy to generate<br>- Collision-resistant                                  | - Less entropy than UUIDs<br>- Not widely supported outside of specific use cases                   | - Smaller size and simpler implementation make it suitable for high-performance and memory-constrained environments |
| **ObjectID**        | MongoDB                         | - Incorporates a timestamp, making it time-ordered<br>- Efficient in MongoDB                               | - Specific to MongoDB<br>- Not universally applicable outside MongoDB                                | - Designed to work seamlessly with MongoDB, ensuring that document IDs are time-ordered and unique                |
| **CUID**            | E. Elliott                      | - Collision-resistant<br>- Short and human-readable<br>- Great for distributed systems                     | - Not as widely recognized as UUIDs<br>- May require additional libraries for implementation        | - Focuses on human readability and collision resistance, ideal for systems requiring easily recognizable IDs      |

Identifier	Creator	Advantages	Disadvantages	Unique Features
ULID	A. Feerasta	- Lexicographically sortable

- 128-bit compatibility with UUID
- Easily implementable in many languages | - Not natively supported in most databases
- Requires additional logic for collision avoidance | - Provides monotonicity within the same millisecond if properly implemented | | LexicalUUID | Twitter | - Ensures lexicographical ordering
- Ideal for ordered database indexing | - Requires custom implementation
- May not be as universally recognized or supported as UUIDs | - Specifically designed to work well with systems that benefit from ordering, such as databases and queues | | Snowflake | Twitter | - Highly scalable and distributed
- Time-ordered
- No central coordination needed | - Complex to implement correctly
- Limited to 4096 IDs per millisecond per node | - Combines time, datacenter, machine, and sequence numbers to ensure uniqueness across distributed systems | | Flake | Boundary | - Similar to Snowflake, provides time-ordered and distributed IDs
- Useful in distributed systems | - Can be complex to manage across different nodes
- Requires consistent clock synchronization | - K-ordered IDs are well-suited for systems where time-based ordering is critical | | ShardingID | Instagram | - Facilitates sharding in distributed databases
- Reduces collision risk across shards | - Implementation complexity
- Requires precise control over ID generation | - Helps with the horizontal scaling of databases by ensuring unique identifiers across shards | | KSUID | Segment | - K-sortable, allowing for lexicographical sorting
- Embedded timestamp
- 160-bit, ensuring higher uniqueness | - Larger size than standard UUIDs
- Not as widely adopted or supported as traditional UUIDs | - The longer bit length provides additional uniqueness and future-proofing | | Elasticflake | P. Pearcy | - Tailored for use with Elasticsearch
- Time-ordered and distributed | - Limited to specific use cases like Elasticsearch
- Less flexible for general-purpose applications | - Integrates well with Elasticsearch, providing efficient querying and indexing | | FlakeID | T. Pawlak | - Simple to implement
- Time-ordered and scalable | - Fewer features compared to Snowflake
- Potentially limited to certain environments | - Focuses on ease of use and simplicity while retaining core benefits of time-ordering | | Sonyflake | Sony | - Optimized for low-latency networks
- Time-ordered
- Scalable and distributed | - Limited to environments with low network latency
- Requires consistent clock synchronization | - Designed for performance in low-latency environments, making it suitable for high-speed transactional systems | | orderedUuid | IT. Cabrera | - Ensures time-ordered UUIDs
- Useful for ordered databases | - Requires custom implementation
- May not be as widely recognized or supported as UUIDs | - Provides the benefits of traditional UUIDs while adding ordering based on creation time | | COMBGUID | R. Tallent | - Combines timestamp with randomness
- Compatible with standard UUID formats | - More complex to implement
- Less intuitive for general use | - Enhances traditional UUIDs by adding time-based components for better sorting | | SID | A. Chilton | - Sequential ID generation
- Useful in systems where order matters | - Limited flexibility
- Not suitable for distributed systems | - Ensures that IDs are generated in a strictly sequential manner, useful for single-system environments | | pushID | Google | - Time-ordered
- Designed for real-time databases
- Short and unique | - Limited to specific environments like Firebase
- Smaller address space compared to UUIDs | - Optimized for real-time applications, particularly in Firebase for efficient and unique key generation | | XID | O. Poitrey | - Compact size (12 bytes)
- Easy to generate
- Collision-resistant | - Less entropy than UUIDs
- Not widely supported outside of specific use cases | - Smaller size and simpler implementation make it suitable for high-performance and memory-constrained environments | | ObjectID | MongoDB | - Incorporates a timestamp, making it time-ordered
- Efficient in MongoDB | - Specific to MongoDB
- Not universally applicable outside MongoDB | - Designed to work seamlessly with MongoDB, ensuring that document IDs are time-ordered and unique | | CUID | E. Elliott | - Collision-resistant
- Short and human-readable
- Great for distributed systems | - Not as widely recognized as UUIDs
- May require additional libraries for implementation | - Focuses on human readability and collision resistance, ideal for systems requiring easily recognizable IDs |

The author published an article with the above table (this article - I'm removing the table because it's bad, but this was where it was) - but it looks terrible in the published version. Will add a screenshot in chat.

So he sent the markdown (the Python that appears first) but that looks bad, too.

So we need to figure out how to properly add tables in Hashnode. Hashnode says to do it like this - with markdown - but this doesn't seem to work as it seems like this is what the author did: https://support.hashnode.com/en/articles/6435291-how-can-i-add-a-table-in-a-blog-post