gizmola

To be clear, is this list supposed to persist between runs? You use the form today, but tomorrow if you use it, is it the same as yesterday, or is it empty?

There is a difference between "I don't plan on doing that anytime soon" and "it's impossible to do that, because I designed the database to make it impossible". I have never seen a commerce system where a product could only have one price ever. No. They are 2 different products. What does version have to do with this? They are not the same product with 2 different versions. They are 2 different projects that have one or more relationships between them. You establish that relationship using the relationship table. Of course, in your system I'm somewhat baffled as to why this is important. Again, if you want to use subtype tables for your product table, as you planned, that is fine. The only things that should go into those tables, are the attributes that are purely specific to their type. Product price is not one of those things, since all Products have a price. That is the rigor that needs to go into determining what is an attribute of a product, and what is an attribute of a product subtype. Now here is the cost: When you do anything with a product, that requires the information in the subtype, you must hydrate the value by joining from product to the specific product subtype table. That is procedural code, vs. a straight relationship between tables and where criteria to limit or filter. As I mentioned, there are ORM's that will automagically take care of this hydration process for you, if you adhere to naming standards and set everything up correctly, but in your case, you will most likely be writing your own customized queries to do this. Why? The book structure should be separate, and should work for an online book whether or not you are selling it. The fact that it's a digital good you will deliver upon sale or membership is something you should engineer separately. Relational databases are built upon relational algebra and set theory. You are confusing the persistence of data that might support oop inheritance with actual relational (and SQL) support for it. If there was support for it, there would be SQL syntax to indicate that. What SQL syntax are you aware of provides you subclassing of a table? There isn't even support for hierarchical SELECT statements. Oracle has Connect By, which is something specific to the Oracle RDBMS, but doesn't exist in MySQL. People have figured out design patterns and workarounds to deal with hierarchical data. By making these seperate type tables and relating them (using a defining relationship) to the Product table, you are utilizing a workaround that will allow you to sensibly persist data, but adds complexity and development cost. I'm not arguing not to do it, but you should at least be aware that it isn't a standard pattern that works with normalization. I have used subtypes myself, so I'm not intrinsically against them, nor am I inexperienced with the practicality of using them. There is no way it would take weeks. I doubt it would take a day. You install it and you start making tables, adding attributes (ie. moving your paper diagram to the model). You relate the tables by connecting them using the tool. When things look right, you hit a button and the DDL spits out. If it's wrong, you fix it in the model and hit the button again. These tools also have useful quality control features like domains. A domain is a datatype you name and configure. So for example, let's say you have a standard description column you use in many tables. You start out with the idea that it should be a varchar(40). So perhaps you have 20 tables with descriptions in them. If you set up a domain, perhaps named "stdDesc" and set each description column to be a "stdDesc" you can change all those attributes in one go, by changing the definition of the "stdDesc" domain. If not, then you have to go change description in 20 tables. Making domains for things like keys, timestamps and other common types will conform the database to standards, so that when you do write your code, you can be sure that quality standards are baked in from the beginning.

It is not complicated. Use a parameter: $pdo_statement=$db->prepare("update tbl_user set logins=7 where user_id=:userId"); $result = $pdo_statement->execute(array(':userId' => $_SESSION['user_login']['user_id'])); Also, you do not ever need to have a ';' at the end of your SQL query. Using the API is not the same as being in the mysql command line client -- each statement is going to be sent for you.

Whatever lines up with your mod_rewrite rules. You should either interpolate your variable or not. You have a mix of the two (concatenation and interpolation). # Interpolation "<li><a href=\"/view/{$cat['CategoryID']}\">$somevar</a></li>"; #concatenation (use single quotes!) '<li><a href="/view/' . $cat['CategoryID'] . '">' . $somevar . '</a></li>';

The function has a simple purpose. It takes the image you clicked on, finds the expandedImg element by it's id, and then sets that img source (src) = to the image clicked on. Remove the things you tried to hack into this and return it to it's simple original form. In particular: Why are you trying to call this onclick that requires an image element in the body onload? What are you trying to do by introducing this line of code: var imgs = document.getElementById("thumbimg"); Adding this is what broke the original function, because you are now forcing this routine to always be the image with id="thumbimg". This is why things no longer work. That needs to be removed, along with the thumbimg id. None of the images in the grid should have an id. To load an initial image, write a new function that finds the first image in the grid. Something like this: function initMainImg() { var imgs = document.getElementsByClassName('column_images')[0].children[0]; myFunction(imgs); } initMainImg(); I can't guarantee this code works, as I'm too tired to test it out right now, but it should give you an idea of how to accomplish your original goal of loading an initial image into the expandedImg div.

These look a lot like registration keys for commercial software. The problem with registration schemes for many commercial products is that the scheme gets reverse engineered and then people are able to generate their own "legitimate" keys that register and unlock software. I was just pointing out that these might look like a registration key, but they aren't.

No worries. I've been storing ipv4 and ipv6 addresses using varbinary(16) for quite a while, and it works well.

Your result set was retrieved from the statement object. You fetch rows from the result, not the statement. $news_result = $news_stmt->get_result(); $news_user = $news_result->fetch_array();

Lots of people are using VSC these days. It should be fine. The best PHP IDE by far is PHPStorm. It's also $200 not including $160 a year for maintenance if you want to keep it updated. There are lots of other editors that do a good job, but I don't see any reason to try and convince you to change. VSC has built in git support so bitbucket should work great for you. The bigger question in regards to a "project" is whether or not you plan to utilize a framework. The 2 premier PHP frameworks are Laravel and Symfony. They are both very capable of supporting systems large and small. They both work well with the composer tool. Taking a look at the documentation for either framework will lead you towards initial boilerplate installs and configuration using composer. In my opinion, the most important thing to know about PHP is that composer exists, and is the dependency management tool that makes the PHP language relevant these days. It's really the first thing you start with for any new project, in the same way that npm is the tool you start with for a node or react project.

I don't use snagit but I do use a similar tool which has preferences you can set for the raster image format and quality. I'm going to assume that snagit has similar settings. I set mine to create a jpg with 100% quality, so that no compression is utilized. The resolution of the image in pixels will be whatever your screen resolution is although snaggit might have a retina specific option, as my tool does. In the case of the tool I use (monosnap) that option is "shrink retina snaps." More about this in a minute... A full screen snapshot on my 15" macbook is 2880 × 1800. But what does the browser actually believe the resolution to be? It actually thinks that the resolution width at full screen is 1440. This is the trickery that Retina plays. You can google more about it if you want the details. So if I choose the "shrink retina snaps" monosnap reduces the screen shot to 1440 pixels wide. At this point, assuming you don't plan to remake all your screenshots, you have whatever you have. Hopefully your original images are high quality, and you retained those.

What good will alternate accounts do for you, if nobody cares to answer your questions?

The points are clear. You need to spend some time learning about mysql datatypes and relational design. Those are your issues, not ours. This is why the comments and links were provided. You also had one question, and then turned on a dime and turned it into an entirely different question, and then one post later, an entirely different question. I don't find that particularly respectful of the people you are seeking help from. Like your database structure, it's intellectually lazy.

Yes.

Yes, make your screen shots however you want them at highest quality. With most quality mobile phones these days, as well as computers with high density displays like the macbook retina displays, you want your images to be 2x the desired size. So if you are going to display an image at 300px wide, then you want the image to be 600px. Here is an article that provides a visual demonstration of the noticeable difference in quality. On an Iphone or Samsung Galaxy, this could make the difference between a screenshot that is blurry and illegible and one that is clear. Having done some mass conversions in the past, Photoshop has tools for automating conversions, using Automate|Batch You should spend more time in the chrome developer tools if you believe this to be true.

The point is that like thumbnails, you have to create different sizes and qualities of the image for mobile. Actually I would disagree. When things don't print well, that is often because styles have not been applied appropriately for all uses or specifically for print purposes. It might not look great, or even correct, but the print to pdf option is going to work, and if that doesn't then saving as html is going to work. Someone who really wants to distribute your content is going to have no problem doing it.

As these are not registration keys AND they still have to be validated, you can simply generate a string of random numbers and characters, perhaps with some dashes between them. Here is a simple routine that will spit out strings in the format of xxxx-xxxx-xxxx, with 256^6 combinations (281 trillion+) combinations. function generateRandomCode() { return substr(chunk_split(bin2hex(random_bytes(6)), 4, '-'), 0, -1); } Very low chance you will generate duplicate codes, but you still want your DB to have a unique index on gift_code, and recover should you try and insert a duplicate. Anything like this would work, as again these are not registration codes, are unique, and would be linked to a particular user.

mod_rewrite will allow you to take a "pretty url" and parse it into the the parameters your site understands. It doesn't automagically translate a url with parameters into a "pretty" url. You need to do that yourself. Hopefully you understand this. You have to understand regular expressions and capturing groups.

If you have a Wordpress site, WooCommerce gives you a way of integrating a store. It's plugin software that enhances your self hosted Wordpress. If your business is run off Wordpress, then it is a good solution. Shopify is Software as a Service/Platform as a Service. You are paying to have your store, and perhaps your entire site hosted and run within the Shopify infrastructure. Ecommerce giants don't use either of these platforms, so the number of downloads or customers really don't matter, other than to provide confidence that there will be support for either platform.

Your plan is fine. Just to throw this out in general, but over 50% of web traffic is now done with a mobile device. I would urge you do some research into responsive design. These days, you want to start with your mobile design and build it up for larger viewports, vs the old days when you started with your primary design and figured out how to scale it down. It's concentrated into css, with the exception of the newer picture element supported by most browsers. Layout is also important. Let's say that you have a layout where you have a picture and next to it a column of text talking about the image. On a mobile device you are going to move that all to 1 column, and will need the descriptive text to go underneath the image. You want to learn grid or flexbox (grid is the current state of the art). Images on mobile is a complicated subject, due to technology like retina. You can't just generate a scaled down version for mobile devices and serve that on a retina device, unless you don't care that the image may become illegible. Any illustrations would be best off rendered in svg, and in fact everything you can render in svg is ideal, because it intrinsically will scale up and down whereas any raster format images won't. Again for the raster images, this is where the html picture element is helpful. I hope that you are not using the web publishing model because you had concerns about "piracy" or content sharing. Having your content in a subscription website won't prevent privacy. Every browser has built in capability to save html, print, and print to pdf.

Please execute a "show create table user" and "show create table minfo" and post the results here so we can see what you are talking about. You want to update user or minfo? What column(s) do you want to update? You can update a table utilizing a join to another table for the purposes of update. For example: UPDATE user JOIN minfo ON minfo.u_uid = user.u_id SET user.some_thing = minfo.some_thing

Yes exactly. You need a productPrice table with a fromDate/toDate pair of dates. I don't really understand your point about not changing prices. Most businesses want to be able to change the price of something whenever it suits them. You require a link to the ProductPrice table for any lineitems in an order, so you have a link back to the historic record of the price. This is an attribute of a Product plain and simple. It doesn't matter what type of product it is. Pricing doesn't belong down in a subtype table, but I'm repeating myself. Again, this isn't logical. But I also explained that a product is a product is a product. There is no need for "versions" of a product when all you are trying to do is establish a relationship hierarchy between products. This is done in systems all the time, and I showed the design pattern that is effective for dealing with that. Yes, but I've only done about 100 commerce, distribution, manufacturing and ERP projects, so what do I know I'm very aware of that, but rather than have a simple straightforward and relationally sound design, you have meandered towards one that is procedural. All I can do is tell you when things look wonky and prognosticate the cost of your decisions in decreased flexibility and reliability, compounded by increased development time to support the design at its most basic level. Once again, OOP is a useful programming language feature in many cases, but is not a feature of relational databases. Nobody asked for that. With that said, selling memberships is a common feature of a gazillion businesses, so it's highly doubtful you have invented a trade secret. The basic relationships with the keys and relations of tables for the ones you are talking about is all anyone expected. A lot of the projects I've worked on have lots of tables, and typically you can only look at a small number at a time. I have worked for companies that had plotters where I would print out a fullsize view of the entire ERD or a large portion thereof a few times in my career, but usually I'm sticking to something that can fit on a page or a large .png that can be viewed on screen. This is what people wanted from you, although it seems like a moot point at this juncture. There are many ways to solve the same problem. You seem satisfied with what you have, so I'm not going to beat a dead horse. I do think that you should be moving on to the construction phase of your project at this point. I know an ERD tool is a valuable time saver, but many of the ones I've used over the years cost thousands of dollars and were paid for by the companies I was working for at the time. I personally own a commercial product I use in my consulting practice, but if I didn't and I wanted something effective and no cost, I'd use MySQL workbench. If you have all these designs on paper, you will be much better off moving them to workbench, and once complete, using it to generate the DDL to create your tables.

Ratings have to be persisted somehow. Anything you find of any real value is going to be an addon to an existing cms, blog or e commerce system. As you already have an existing system, the best idea would be to add ratings onto it. The database structure required is not that difficult to create and code.

I'm not going to help you debug your php/mysql code if it's going to use php interpolation of variables into SQL strings. It's up to you if you are going to adopt modern practices.

Awesome. Also, to be clear, if you use prepared statements, you don't need to worry about escaping data, which also means you don't have to worry about SQL injections. You level right up

Hi jodunno. I thought I'd chime in and say one thing about your original concern. A relational database is meant to be a black box. You never need to poke in the individual files the underlying database server creates or manipulates. You only talk to your database and manipulate it via SQL. A relational database management system like MySQL is inherently a client/server system where the server runs persistently and the client connects and talks to it via SQL. The .ibd file is literally the innodb file for the user_settings table. Anything you do to that file would likely corrupt and destroy the table and its contents. Innodb files are actually clustered btree indexes stored in primary key order. You have root/master access to your data. This gives you a way of looking at those files, but other people can't.