JDE EnterpriseOne 8.98.4.1 Data Dictionary? I've used Databrowser to locate data items in F9210 - in this case Long Address data fields. Now how do I xref this field into tables, views, forms and reports where it is utilized?
Any JDE Data Dictionary pointers would be HUGELY appreciated.
The version i am currently using is 8.98.41; the same as you.
You could fast path into P980011, this brings up a JDE Standard App that can be used for cross referencing Data Dictionary items and its use in all objects.
If you were to do it the SQL/UTB way, it would be quite hard as event rules are stored in a BLOB column in one of the LocalSpec tables.
Related
I need to store a complex C# object in SQLite in my mobile app. I know that a complex object can be broken down and stored in multiple tables.
In my particular use case, however, I don't need to query the data. Is there any problem in serializing my complex object and then storing it as a string in my SQLite table?
I only need to store it temporarily as I collect data from the user in multiple screens and there will only be the data I store during the collection process. In other words, once the data collection is completed, I will remove the data from my SQLite table.
I've already tried it and it works fine but want to see if there are some issues that I may run into in the future?
I need some help thinking about the design for my business objects.
Our database records the daily entry and exit times for the comings and goings of the employees in our company. Each record also stores the UserID of the employee, the ID of the work station the employee signed in at and obviously the date.
A user can have many Entry and Exit times at any number of work stations at any given date.
The record looks something like this:
SignInID | UserID | WorkStationID | DateTimeEntry | DateTimeExit
I have a reportviewer on my asp.net form that must display reports of this entry and exit data grouped by date, work station or user.
For example it must display all data for a specific date (and within that, ordered by work station).
Or it must display all data for a given work station (and within that, ordered by date) and other similar formats.
Until now I had a monstrosity of a method where I selected the data and constructed some kind of makeshift datatable to display on my form.
I now want to redesign using objects, but I don't know how to design the hierarchy i.e. what object contains the collection of entry and exit times, and how to I make it flexible enough that I can query it (using Linq, perhaps?) based on the various display criteria?
I'm really interested in learning more about designing objects and using the correct terminology for what I'm trying to do, so if you can point me to some articles explaining these concepts it would be very helpful too.
EDIT: Okay, at least I've learned something new. What I'm trying to do is ORM - Object-relational mapping - and .NET has an inbuilt ORM tool called Entity Framework. So far so good. Now I have to see whether it can help me figure out how to organize my data.
Well, I actually have to thank the community for not answering my question, because I got to learn a lot about Entity Framework, Linq (and its limitations with Entity Framework in .NET 3.5) and a whole bunch of other things to answer my own question.
What I ended up doing was create an Entity Model of my Database using Entity Framework and thus created the Business Objects I needed to organize my data. I learned that my data isn't designed in a hierarchy, rather there are associations such as Workstation and User that each time entry records contains. I used a Linq-to-Entities query to select the data I wanted and flattened it out using its associations (example Time.Workstation.Name or Time.User.FullName) so that in the end, my projected object contained all the data I wanted in each row of my report. My projected object was actually a POCO I created for the purpose of holding the queried data and making it available as a datasource for my rdlc report.
Finally I bound the results of my query to a Reportviewer's ObjectDataSource which connects to the rdlc file that I was able to define to my liking: i.e. Either displaying the Workstation first or the User, or whatever associated information I wanted to display.
I have an ASP.NET data entry application that is used by multiple clients. The application consists of multiple data entry modules that are common to all clients.
I now have multiple clients that want their own custom module added which will typically consist of a dozen or so data points. Some values will be text, others numeric, some will be dropdown selections, etc.
I'm in need of suggestions for handling the data model for this. I have two thoughts on how to handle. First would be to create a new table for each new module for each client. This is pretty clean but I don't particular like it. My other thought is to have one table with columns for each custom data point for each client. This table would end up with a lot of columns and a lot of NULL values. I don't really like either solution and suspect there's a better way to do this, so any feedback you have will be appreciated.
I'm using SQL Server 2008.
As always with these questions, "it depends".
The dreaded key-value table.
This approach relies on a table which lists the fields and their values as individual records.
CustomFields(clientId int, fieldName sysname, fieldValue varbinary)
Benefits:
Infinitely flexible
Easy to implement
Easy to index
non existing values take no space
Disadvantage:
Showing a list of all records with complete field list is a very dirty query
The Microsoft way
The Microsoft way of this kind of problem is "sparse columns" (introduced in SQL 2008)
Benefits:
Blessed by the people who design SQL Server
records can be queried without having to apply fancy pivots
Fields without data don't take space on disk
Disadvantage:
Many technical restrictions
a new field requires DML
The xml tax
You can add an xml field to the table which will be used to store all the "extra" fields.
Benefits:
unlimited flexibility
can be indexed
storage efficient (when it fits in a page)
With some xpath gymnastics the fields can be included in a flat recordset.
schema can be enforced with schema collections
Disadvantages:
not clearly visible what's in the field
xquery support in SQL Server has gaps which makes getting your data a real nightmare sometimes
There are maybe more solutions, but to me these are the main contenders. Which one to choose:
key-value seems appropriate when the number of extra fields is limited. (say no more than 10-20 or so)
Sparse columns is more suitable for data with many properties which are filled out infrequent. Sounds more appropriate when you can have many extra fields
xml column is very flexible, but a pain to query. Appropriate for solutions that write rarely and query rarely. ie: don't run aggregates etc on the data stored in this field.
I'd suggest you go with the first option you described. I wouldn't over think it. The second option you outlined would be a bad idea in my opinion.
If there are fields common to all the modules you're adding to the system you should consider keeping those in a single table then have other tables with the fields specific to a particular module related back to the primary key in the common table. This is basically table inheritance (http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server) and will centralize the common module data and make it easier to query across modules.
I have an existing, mature schema to which we need to add some new Product attributes. For example, we have Products.Flavor, and now need to add new attributes such as Weight, Fragrance, etc. Rather than continue to widen the Products table, I am considering a couple of other options. First is a new Attributes table, which will effectively be a property bag for arbitary attributes, and a ProductsAttributes table to store the mappings (and values) for a particular product's attributes. This is the Entity-Attribute-Value (EAV) pattern, as I've come to understand it. The other option is to add a new column to the Products table called Attributes, which is of type XML. Here, we can arbitrarily add attributes to any product instance without adding new tables.
What are the pros/cons to each approach? I'm using SQL Server 2008 and ASP.NET 4.0.
This is (imho) one of the classic database design issues. Call it "attribute creep", perhaps, as once you start, there will always be another attribute or property to add. They key decision is, do you store the data within the database using the basic tools provided by the database (tables and columns) to structure and format the data, or do you store the data in some other fashion (XML and name/value pairs being the most common alternates). Simply put, if you store the data in a form other than that supported by the DBMS system, then you lose the power of the DBMS system to manage, maintain, and work with that data. This is not much of a problem if you only need to store it as "blob data" (dump it all in, pump it all out), but once you start have to seek, sort, or filter by this data, it can get very ugly very fast.
With that said, I do have strong opinions on name/value pairs and XML, but alas, none are positive. If you do have to store your data this way, and yes it can be an entirely valid business/design decision, then I would recommend looking long and hard on how the data you need to store in the database will be used and accessed in the future. Weight the pros and cons of each methodology in light of how it will be used, and pick the once that's easiest to manage and maintain. (Don't pick the one that's easiest to implement, you'll be supporting it for a lot longer than you'll be writing it.)
(It's long, but the "RLH" essay is a classic example of name/value pairs run amok.)
(Oh, and if you're using it, look into SQL Server 2008's "Sparse Columns" option. Doesn't sound like what you need, but you never know.)
I want to store data which is dynamic in nature. The user can create forms for capturing data. The data can be stored in various formats as per the configuration. The major ones are a RDBMS and a XML file. XML file format is pretty easy to store dynamic data and load it back.
I am not able to devise a data structure for a RDBMS. I currently store data in a key-value format and do a PIVOT for fetching it. For fields which have multiple values I store them as CSV in the value column.
Is there a better way for storing such dynamic data which helps in performance and extensibility?
Without knowing more about your application it is hard to say.
You could save the data as XML in a BLOB in the database. That would mean all your data was (sorta) handled the same way (as XML).
The other approach would be to change your database structure to hold nested data (which appears to be your problem). So instead of a straight key-value table you might hace a table structure that could reference itself (e.g. parent - key - value) and have a header table to hold the top level keys.
The real question though is why you want to use a database to hold the data. It seems the real problem is trying to fit a round peg into a square hole (or vice versa).