I been using postgres for a while. Mostly simple stuff.
Now trying to implement a small perl function to check for a single valid email address.
My employees table should have either a single valid email address, or none (ie empty, zilch).
I assume none means undef(email)
My sample code below...
This was answer yesterday by @PeterVandivier but the guy accepted another answer...
Well, I disagree. It's not the same thing. It might be similar but not the same. 5 backups per day in simple mode means that you have 5 restoring points in time per day. Full mode properly done means you can restore in any point in time. — ypercubeᵀᴹ4 mins ago
I will give the answer the benefit of the doubt (about their intentions) and not downvote for the moment.
Guys, guys, you might be underappreciating the one aspect to that answer that may be most beneficial to the OP, and that is: it says exactly what the OP wants to hear.
@PeterVandivier Yes, me too. But actually on your answer. The reason? Well just running Ola's script does not ensure your databases receive the TLC they require. Huh? Yes, Ola's scripts don't come with a schedule. (you won't find any sp_add_jobschedule steps in the script) You need to implement a schedule for the jobs and seeing as the OP is not very fluent in backups, I would say that your answer is missing some points. Sorry if I'm a bit too blunt pointing this out.
Well, speaking about the question you VtC'ed, basically you need to cover two cases: 1) you need PITR; 2) you don't need PITR. Is there much more to it?
I mean, that's what need to be stipulated answering the OP's main question:
> My exact question: Is generating multiple daily backup with simple recovery model, similar to full recovery backup with longer period?
@hot2use editted to try and incorporate the necessary info, but of course feel free to add info/make a community answer if you feel i've missed something important
Trying to make an apple id, running into all their password rules: - no more than 3 consecutive same characters - no special punctuation characters (whatever "special" is) - at least one uppercase
Looking for advice on file format/configuration system. I have complex transform rules and right now the informaticist can edit an Excel workbook and I can validate this and pull it into configuration tables. But the Excel workbooks need to get more powerful to enable editing in certain ways and lookups and parent-child relationships. In addition, putting these in version control is problematic because you can't easily get usable diffs.
XML would be ideal since it can get diffed pretty effectively and is easy to validate and just as easy to load. But editing tools? Would need something pretty easy and customizable. Considering using Excel (for editing) -> XML (for diff/version cotnrol) -> SQL (runtime) so that the build process maintains the XML automatically.
Everything the informaticist needs should be in whatever they are editing it.
For example, just for them to be able to review the data modeling with hospital analysts, I already have a dedicated tool which generates sample data from some combinations they can create so they can see if it makes sense in PowerBI before we even worry about populating the model from the source data using the mapping rules.
There's no more syntax in YAML than there is in a bullet list in a Word document. Any informaticist should be able to handle bullet lists. those who can't should bite the bullet.
Are there any tools which would let them have pick lists?
There are going to be thousands of these mappings.
The kind of thing they are doing in the modeling is taking a particular observation in a cardiac catheter study and deciding that it has a severity and then some child attributes. And the child attributes may be reused between different types of observations.
If there is a YAML editor which has some kind of schema validation/intellisense, that might work.
It's hard enough just trying to get the model validated in PowerBI, LOL.
Currently sitting through a meeting where trying to make PowerBI do things that it isn't very good at.
This meeting really reminds me that no matter what you do, you can never make it easy enough for someone to to do all the analyses that they will think of. Eventually someone will need to write queries.
The whole purpose of our structured reporting system is to get users from having to make copious free text entries like this to structured data that can be analyzed.
Such a mixture of questions on the site at the moment. There’s some really good, hard, SQL Server questions, then a load of utter dogcrap 🐕 from students