We want to store list of countries and thier counties/states for our latest Umbraco project.
These country and county ids are required in other modules for filtering and searching.
We are not using any custom database tables or custom sections all modules.
One option we found is to store country and it's counties as Umbraco Content Library nodes, but not sure about the performance impact.
Is there any other suitable way to overcome this situation?
Umbraco content library nodes are perfect for this:
The number of countries is limited, therefore no risk of having thousands of entries all of a sudden
The data is probably not updated frequently.
This will be published to umbraco.config which is accessible via xslt and cached in memory - performance impact: very fast!
States can be stored as child nodes of each country
Other content nodes can be linked with built-in content pickers to countries/states (and filter/search etc).
Integrated Umbraco functionality (publishing, node order, etc.) can be used since they are just nodes
No need for a developer to add a state/country (though you probably want to import the first batch...)
You may consider grouping countries in regions (or similar) because approx. 250 nodes is still a lot of nodes to look through in the content library.
There is another way to store these data - static file, such as Xml.
But this way has some limit:
1) you can not manage these data in Umbraco
2) You have to write your own code to read these data.
I'd go with the Content Library option. But you may also find something useful here:
http://ucomponents.codeplex.com/documentation
Related
In the absence of DML (not leveraging Delta Lake as of yet), I'm looking for ways to manage Static/Fixed-Content Dimensions in a Data Lakehouse (i.e. Gender, OrderType, Country).
Ideally the schema and data within these dimensions would be managed by non-technical staff, but at this point, I'm just looking for development patterns to support the concept technically without being able DML. Preferably with history on source (who added 10 rows to this dimension?)
Thank you in advance for any assistance.
The Lake/Lakehouse/Warehouse should not be the system-of-record for any of your data. So you have another system where that data is "mastered" and then you copy it. Just like anything else.
The "system-of-record" can be a SharePoint List, an Excel workbook on OneDrive, a Dataverse table, or whatever you find convenient and is accessible to the people managing the data.
I'm creating a knowledge graph from text documents, This will include document nodes.
I want to store the entire text of these documents as a node property.
Is there anything inherently wrong with this?
Would it be better to store this information elsewhere and then just store a reference to that instead?
Are there any limitations to the amount of data you should add to nodes or relationships?
You can check these two options:
Store the relationships in a graph database and the document
information in a different database, such as CouchDB (Cons: managing
the two stores and keeping them in sync).
If you have text, then you need to think more about what kind of graph you're trying to get out of it. Do you want person/place/thing
information linked together? Then you might check out the GraphAware
NLP plugins for Neo4j - but they work on the text, not on docs/PDFs.
I am building an iOS application that will randomly generate sentences (think Mad Libs) where the data used for generation is in multiple tables. This will be used to generate scenarios for training lifeguards. Each table contains an item name, the words that will be used when selected, and different values that determine what can go togeather.
Using two of the 10 tables shown above, the application may pick a location of Deep Water. Then it needs to pick an appropriate activity for in the water, such as Breath holding, but not Running.
I have been looking at Core Data for storage but that seems to be more for data that is changing often by the user and users would never change the data stored. I do want to be able to update the tables myself fairly easily. What would be the optimal solution to do this? The ways I think of are:
Some kind of SQL DB, though my tables again aren't changing and
aren't relationshipable.
2-D arrays written into the source code. Not pretty to work with or read, but my knowledge of regex makes converting from TSV to array fairly easy.
TSV files attached to the project. Better organization itself but take some research on how to access.
Some other method Apple has that I do not know about.
I am working in a big company and we are having a lot of JIRA projects, I would like to have a dashboard or a way to know if the projects that exist in JIRA are used, e.g if there are any issues in them (I don't need to see the issues just to have a number).
Can I do it without accessing to the database, do I need a plugin, is there a functional way to get the info? :)
thanks a lot
best regards
Adrien k
You can easily do this with the built-in Two Dimensional Filter Statistics gadget:
first, search for all issues in your JIRA instance. There may be an easier way to do this, but you can certainly use JQL like project=ABC or project != ABC.
save the search as a filter
go to a dashboard, add a new Two Dimensional Filter Statistics gadget. Select your newly-saved filter, select "Project" for one axis, and something small in number (like Issue Type) to the other axis. You'll also need to adjust "Number of Results" to exceed the number of issue types in your system.
save the gadget
Note that the Projects gadget also provides somewhat-similar information with fewer configuration requirements, but as far as I know, it doesn't show the numeric issue totals unless you hover the mouse pointer over the bars.
The company I work for makes a plugin that can do that - Structure
That's an example structure containing all issues in available projects, they are then grouped by project, and there's a column showing the number of sub-items (issues) in each group (project).
You can also add a structure to a dashboard/Confluence page.
On a large JIRA instance it be a bit on the expensive side to use it just for that alone though...
MS's OneNote uses a data hierarchy that is essentially a simple tree, even though the info is displayed via a tabbed interface rather than a treeview. You begin with "notebooks," which can have "sections," which have "pages." I'm trying to model this. In my case, a page would be linked to the contents of a RichEdit.
My problem is not that I can't figure out a way to do this. My problem is that I am unsure which of several possibilities will ultimately be simplest. That's where I am hoping you will come in.
I could, for example, use a regular [MyBase] database. A Page dataset would have fields for its name, and the RichEdit data. Pages would be nested inside Sections, and Sections would be nested inside Notebooks.
If I thought about it for awhile, it seems like this is something that could be modeled with simple stringLists as well, especially if each element in the list included comma separate values for an ID and position in the hierarchy, as well as notebook/section/page name.
But then this also seems like something that might be well suited for XML ... if I were to learn more about XML :-)
What do you more experienced folks think?
Thanks, as always ...
Whether you go with a database or XML, try putting your data access routines in a datamodule. Let your GUI unit(s) make calls to public methods of the datamodule, and ensure that those calls do not depend on how your data are stored. That way, you can start with one approach, and switch to the other just by editing your datamodule.
One thing you could try would be to use a structured storage system. The concept is simple, you work with a datafile much like you would a disk and folders...thing is that the folders and files are all under your exclusive control. The only issue is that it doesn't exactly scale well to multiple users, but then neither does XML. (a good structured storage library is available on gabr's blog)
For a "multi-user" system, your best option will be to implement using tables. You can probably get a good start at things using Microsoft Access and ADO, which migrates to MS Sql Server very easily. From your brief description, I would expect you to have three tables, NOTEBOOKS, SECTIONS, PAGES. The Pages would have a Foreign key relationship (detail/master) to Sections and sections would have a Foreign key relationship with Notebooks.
If you are storing it in a file system, why not use.... folders? That's what OneNote does. A "notebook" and a "section group" are simply regular file system folders. The only other level is a section which is the .one file. There is a very limited hierarchy in there (it's just pages, any of which can be marked as subpages but these are not really linked in any way to a parent.)
Inside the .one file you can use XML to represent your pages, though this is not what OneNote does. OneNote uses a binary file format in order to facilitate fast edits, object-level synchronization, multi-user access, and compact storage.
If you look around for info about "random access files" you can get an idea for how to do this. But try to avoid using XML if you think it can get large because it will become cumbersome to make edits. You'd need to load the entire XML file, make changes in-memory, then write the whole thing back out again.
I think it depends on how you want to save the data. If you plant to use a database for shared access, speed and large amounts of data: just normalize the data and create the structure you proposed.
If you want the user to save data locally on a filesystem, I do think that XML will be a good solution because it allows you to store the data in a structured file.
So... how do you want the user to store and use the data?
I think at your data like a tree.
node {
id
parent_id
content
type
}
nodes with paren_id = 0 are notebook.
type is optional but could be useful.
content on page and notebook will give you a page/notebook description for free :D
I will use a simple table on sqlite or MyBase or whatever.
I think a little db is better than Xml because xml force you to load all data in memory.