we used to write stored procedures to parse text and identify all related objects in views. Are there any alternatives or examples
Yes, there is a function that you can use to retrieve all object references (currently limited to views)
https://docs.snowflake.com/en/sql-reference/functions/get_object_references.html
Related
I would like to know how to determine if an object in SAP has either transactional or master data. I do not know where to locate this information if it even states it anywhere within the datasets. Also, if it has to be determined based on certain criteria then please let me know so I will not be expecting to see it as an additional field or something. Thanks in advance for your time!
There is no such criterion, it's up to context, if we speak about custom tables. It's up to the company that uses SAP what is transactional in their business, and what is master.
If we speak about standard tables, then you can use Data Class (reachable by Ctrl+Shift+F9 on target table):
However, this attribute also cannot be treated as a 100% reliable way.
I'm building a mobile application that records information about items and then outputs an automatically generated report.
Each Item may be of various types, each type requires different information to be recorded. The user needs to be able to specify what is to be stored for each type.
Is there a "best" way to store this type of information in a relational database?
My current plan is to have a Type table that maps Types to Attributes that need to be recorded for that Type. Does this sound sensible? I imagine that it may get messy when I come to produce reports from this data.
I guess I need a way of generalising the information that needs to be recorded?
I think I just need some pointers in the right direction.
Thanks!
Only a suggestion, might not be an answer... use JSON and go for no-sql database. Today it is more convenient to operate and play around with data in not strictly relational database format.
That way you can define a model(s), or create you own data structure as mentioned and store it easily as a collection of documents of that model. Also no-sql allows structure changes without obligating you to define entire "column" for all "rows" present there ;)
Check this out about MongoDB and NoSQL explanation.
This is also a beatiful post that i love about data modeling in
NoSQL.
What would be the best way to tie a database object to a source code implementation? Basically so that I could have a table of "ingredients" that could be referred to by objects from another table containing a "recipe", while still being able to index and search efficiently by their metadata. Also taking into account that some "ingredients" might inherit from other "ingredients".
Maybe I'm looking at this in a totally wrong way, would appreciate any light on the subject.
If I've correctly understood your goal, there should be these two choices:
Use an OR/M and don't try to implement the data mapping yourself from scratch.
Switch to a NoSQL storage. Analyze your data model and see if it's not very relational and it can be expressed using a document storage like MongoDB. For example, MongoDB already supports indexing.
I'm currently building an app that contains around 60 or so tables, some with meta information, some with actual data and a couple of views on top of them.
To keep things organized I'm prefixing all table name with meta_ or view_ respectively, but might it be worth it to just put them in different schemas inside the same database?
It this common practice?
Any reasons to not do this?
Can I create FK-constraints over different schemas?
PS: There seems to be no performance penalty judging from this answer: PostgreSQL: Performance penalty for joining two tables in separate schemas
You can use schemas in any way you like. No limitation in principal. They are especially useful if you need to GRANT certain rights to groups of objects, for instance to separate users inside a database. You can largely treat them like directories in a file system (the analogy has its limits, though).
I use v_ prefix for views and f_ prefix for functions. But that is basically just notational convenience to spot those objects quickly in a text search - if I hack the dump for instance. Make such prefixes short, you will have to type them for the rest of your database life. Multiple prefixes from various semantic layers could have to apply to a single object.
I would not mix functional prefixes (v_ or view_) with semantic prefixes (meta_) on the same level. Rather create a separate schema for meta-objects and use prefixes to denote object types throughout all your schemata.
Whichever system you chose, stay consistent! Or it will do more harm than good.
When people talk about object impedence mismatch, where does the mismatch happen? What can't a database interpret from an object model?
Thanks
Usually because Objects can inherit methods and properties from other Objects and in a relationship database there is no equivalent.
See the following for more information:
http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch
The basic difference is that databases / relational model are based on sets (rows) of data that are globally available, whereas object-oriented models are based on trees of encapsulated, or hidden (not globally available) data. The two approaches are philosophically at odds - one exposes all (clumped into tables, organized by traits), the other hides all (clumped into nodes, organized by things). To go from relational to object-oriented, global trait data in rows have to be split up and hidden in things. To go from object-oriented to relational, hidden thing data in objects have to be collected into rows and exposed. This can be a lot of work, and there are many different ways to approach it, depending on your situation.