New answers tagged

0

Although its a 3 years old thread, still I'm replying it thinking that it might be helpful to somebody. Table Structure Table_Offer -------- ID FK Name start time end time MandatoryGroup -------- ProductId (FK to product) MixGroup1 -------- ProductId (FK to product) MixGroup2 -------- ProductId (FK to product) Table_offerDetails --------------...


0

being able to save and restore that sequence from disk Are we talking about a file system, here, or a "DB", as in your posting's Title? In the file system, just write your list items into a file. They will be stored in the order you want them and you can read them back in the same order. Notepad does something remarkably similar. If you did want to ...


0

So my problem is, I have users entering their data(names, address) in a mixed form- some with first letter in caps and some without, some inserting more than necessary spaces and so forth. To reduce this "noise", redesign your UI to capture this data in a more "structured" form, i.e. separate fields for Title, Forename(s) , Surname. However, bear these ...


1

I think most applications should have them. These values are more of a convenience for trouble-shooting and other support needs. Soft deletes have benefits as well, but you always have to include them in your query logic. Just because you can use them, they're not enough. Many auditing needs require more data and sophistication even beyond logging. ...


3

would it be a 'bad idea', to implement a policy/practice to always persist data and to always implement 'auto-updating' (if possible) created, updated and deleted properties? Persistence and auditability (not stated but implied) are valuable goals, and it is good to think in that direction for cases where you need them. That said, to answer your questions: ...


3

Let's take the example of a major ERP on the market: all the master data and most of the transaction data carry 4 fields: the author and the time stamp of the record creation and of the last record modification. all the critical field changes (it's customizable what is critical) are logged with the author of the change, the timestamp of the change, the ...


3

No, it is not too verbose. I'd say it's close to being a best practice. Having created and modified dates on a per record basis allows one to see how stale that particular data row is. Most systems I have encountered have data retention requirements. By having these dates, one can have a data purge process to keep only a certain amount of data in a ...


0

The cleaner solution would obviously be to track states for every single attribute individually, as with your first approach. It's not as bad as you make it though, as reconstructing a past state is as simple as just ignoring all new state changes introduced later on, so just a simple WHERE date < ... GROUP BY attribute.order_id ORDER BY date DESC, and ...


0

Think about security too. If you identify these records EVERYWHERE by data that may be sensitive - will there eventually be sensitive data somewhere it shouldn't? 'Shouldn't' being defined by requirements, client needs, and the Data Protection Act. It might be 'encrypted', but I assume if you want it for efficiency of cross-checking - it won't be heavily ...


0

Including information in the Id of the record: The upsides: Minor (but debatable) initial convenience to the few humans who need to read the underlying data store. The downsides: Nearly impossible to make changes. What happens when the Id suddenly needs to include information X? What happens when information X needs to be removed, or becomes ...


-1

There was a discussion about whether it was desirable to have information about each person encoded in their ID number. Encoding multiple items of data into a single field is Bad Design if for no other reason than it breaks basic Data Normalisation rules. Alternatively, it could contain no semantic content at all. That would be my choice. On ...


0

The EAV design is a way to allow users/admins a way to create custom fields without requiring additional coding for each item. They can be read and applied dynamicall. They're more suitable for lookup type values. There's nothing in your description about your app that needs this functionality, so you coworker is using a bad design. If creating fields in a ...


2

But a coworker said that in my design we would have to alter table every time we need to add new property (which I agree) I agree too. What's the issue exactly? When you add new features you sometimes have to modify the database. Sounds fair enough to me, I know how to deal with that easily. In his solution we wouldn't have to alter table at all in the ...


7

Your coworker's design is a well-known antipattern known as "entity-attribute-value". It looks really attractive at first due to its flexibility, but experienced developers know it's a very bad idea because it eliminates all of the advantages of using a relational database in the first place. When you have a (normal-style) table that describes the ...


0

How about this: +-----------+ +------------------+ +-------------------+ | | | | | | | | | | | | | Game | | GameProperty | | Property | | +-------> <-------+ ID (PK) ...


1

I like your co-workers design better with a slight adjustment. Depending on the content of both propertyName and propertyValue, further decomposition might be better so you don't have redundant data. You'd then have either two tables: PropertyName (with Id and Name fields) GameProperty (the current propertyName would be idPropertyName instead, a foreign ...


3

The reason why you often have a database for each micro-service, is in order to separate each part of the system. If you store everything in one database, you will (as mentioned by Michal Kosmulski) lose some scalability. But more importantly, each micro-service might be better off with some other form of storage. Some of your micro-services might be best ...


4

"Best" is relative. Microservices do come with a performance penalty for some cases, which is offset by better scalability. It may seem like a paradox, but you need to make an individual operation slower in order to make it possible for the system to scale better. In your case, better scalability means you can't handle complex state changes between many ...


0

What about different table for different type of user. And one table for common information of user. Then specific table have a reference to basic info rowID RegularUser { ID, SpecificDataForRegularUser, BasicInfoID} Manager { ID, SpecificDataForManager, BasicInfoID} UserBasicInfo { ID, Name, Phone, ...} Then data structure for different type of user ...


1

It sounds like you are digging around in the implementation details of a large product that (probably) is designed to be used via GUI's and APIs. In your position, I would be asking myself why I was doing this. Probably you would be better off not >>trying<< to understand. If you really need to know this kind of thing, then you are probably trying ...


2

As with all things software, 'unlimited' merely means 'limited by the system, not the developer'. A 64-bit int would allow you to store 18446744073709551615 ticks. Precision vs Scale Now, this is where you get to trade precision for scale. If you use ticks=microseconds, you'll get just over 1/2 million years to play with. Milliseconds gives you 1/2 ...


1

Rough Modeling The conventional aspects of house design and construction suggest modeling with a domain specific language that captures the business logic of dwelling and dwelling life cycles might be easier than using a general purpose programming language. Rough Mathematics Though there are bounds on house configuration from convention, mathematically, ...


4

Database Normalization First Normal Form (1NF) Eliminate duplicate columns Create separate tables for each group of related data You should create a table employee_access and each time a employee enters or quits the building record the date and time: id, employee_id, date_time, operation operation field should contain IN or OUT You may ask why not ...


3

It should not be in the employee table because you will have columns named "entrance_Sunday", "exit_Sunday", "entrance_Monday", etc. This is a very bad design. Suppose you have another table with a column containing a "day-of-the-week" value. You won't be able to join these tables without some very ugly SQL: SELECT CASE calendar.day_of_week WHEN '...



Top 50 recent answers are included