Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Question #1: are DBs useful for storing such data, and how should it be done? </p> </blockquote> <p>Certainly a database is useful for this application. You could implement your own special-purpose data store, and perhaps it would be more efficient for your specific application, because you can design it for that specialization. A relational database is more general-purpose, but you can avoid weeks or months of development time by employing a database.</p> <p>I answered another question earlier today on the subject of how to handle extensible types, where each new sub-type has its own distinct set of attributes. </p> <p>"<a href="https://stackoverflow.com/questions/695752/product-table-many-kind-of-product-each-product-have-many-parameters/695860#695860">product table, many kind of product, each product have many parameters</a>."</p> <p>For your application, I would choose the <a href="http://martinfowler.com/eaaCatalog/concreteTableInheritance.html" rel="nofollow noreferrer">Concrete Table Inheritance</a> design.</p> <blockquote> <p>Question #2: Now suppose the user himself can specify the format of his packets, i.e. in a configuration file: the length of each field, its type, what its values mean (in case of an enumeration) and so on. How do I extend a DB-backed implementation for this? </p> </blockquote> <p>I assume the number of packet types are relatively few, and then many packets are inserted with pretty much the same structure. So you should use the database's ability to manage metadata. I would define an additional table for each new packet types.</p> <p>I would also store the packets "exploded" so each field of the packet is stored in a separate database column. That way you can index each column individually, to support efficient searching.</p> <p>You can also define constraints so that some fields are mandatory (<code>NOT NULL</code>) or their values constrained by lookup tables. Again, leveraging the database's capabilities to use metadata to enforce consistent structure where it's desirable.</p> <p>SQL already supports a standard, declarative language for specifying fields with data types, constraints, etc. Why develop a different language which you then have to translate to SQL?</p> <blockquote> <p>Question #3: Even more advanced... Now suppose the data packages can be varying in length and contents.</p> </blockquote> <p>Fields that are optional in a given packet type should permit <code>NULL</code> in the corresponding column.</p>
    singulars
    1. This table or related slice is empty.
    1. POStoring data packets in a database
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USBill Karwin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POStoring data packets in a database
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COcan this perhaps be better solved with an ORM like SQLAlchemy, or is it irrelevant to my needs?
      singulars
      1. PO
      1. USEli Bendersky
    2. COalso, could you please clarify what you mean by "ability to manage metadata"? what kind of metadata suites me best here?
      singulars
      1. PO
      1. USEli Bendersky
    3. COBy metadata I mean a table, consisting of columns and constraints. An RDBMS uses metadata to enforce data types, NOT NULL, referential integrity, etc.
      singulars
      1. PO
      1. USBill Karwin
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload